n find in CVS are
welcome.
Wichert.
--
Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
Previously Adam Heath wrote:
> On Sat, 8 Nov 2003, Josip Rodin wrote:
> > (FWIW, I've seen doogie mention thinking of moving debian/ to dpkg/ at some
> > point.)
>
> I don't recall this. However, I could see mv debian deb.
I said that.
Wichert.
--
Wichert Akk
ll always work.
I'm cc'ing this to debian-policy since it might be wise to come up
with a policy on this topic. (note that I'm not subscribed there)
Wichert.
--
Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/
A random hacker
ng.
It is pretty easy to script a test for this one could run on an
archive before a release.
Wichert.
--
Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/
A random hacker
I think a different solution: check for this problem when build a
package and abort if you hit it. That is trivial to implement as
a linda check or standalone tool you can call from debian/rules. In
fact I think dpkg-scanlibs already does that.
Wichert.
--
Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/
A random hacker
Previously Colin Walters wrote:
> Opinions?
I second this proposal.
Wichert.
--
Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/
A random hacker
;m tempted to make the next dpkg release abort if people try
that.
Wichert.
--
Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/
A random hacker
nds on the dselect method I think, but the most popular one by far
(apt) indeeds uses the compressed version.
Wichert.
--
Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/
A random hacker
ile will increase 516343 - 25919 = 490424
bytes, or around 479 kilobyte. That is a lot of data for people using
modems.
Wichert.
--
Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/
A random hacker
example that exepect all
the data to be in the Packages files.
Wichert.
--
Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/
A random hacker
too...?
It is relevant to the discusison though.. do we want to bloat the
Packages file with usptream author & homepage information as well?
Wichert.
--
Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/
A random hacker
Wichert.
--
Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/
A random hacker
be a new preferred way of setting that data. Tools that parse this data
will not notice the difference.
Wichert.
--
Wichert Akkerman <[EMAIL PROTECTED]> http://www.wiggy.net/
A random hacker
Previously Joey Hess wrote:
> Well my proposed wording also recycles it, it just lets us get bits of
> it back from the admin in extreme circumstances.
In extreme circumstances we can always ask the admin no matter what
policy says.
Wichert.
--
Previously Andreas Schuldei wrote:
> actually, the idrange from 6-64999 could be used by joey,
> too, if we redifined it properly. it could say something like
> 'only on debian project owned machines'. (i understand the
> description of that id range to apply to those boxes, no reason
> to clog
Previously Joey Hess wrote:
> What if we change the "Reserved" for 3-5 to "Reserved for use
> at local admin's discretion", and then something like my package can
> just ask[1] if it's ok to use a set in that range; an admin who is using it
> for something else like a large NIS or whatever
Previously Joey Hess wrote:
> Well, I have a package that really needs a minumum of 100 but ideally
> 1000 semi-static uids of its own (the block should be contiguous; must
> have _no_ user in the password file for at least a large percentage of
> them; don't ask), but I have not dared to bring it
Package: debian-policy
Severity: wishlist
We have reserved the 3-5 uid/gid range for ages, but never used
it and observing the current rate of growth I don't think it makes sense
to keep them reserved: Debian will not use that range in the next
century, while large systems definitely can u
reassign 159744 debian-policy
thanks
Folks, please get a consensus and stop this stupid reassigning and
closing/reopening. The bug was cloned and one of the clones is
assigned to dpkg-dev already, so reassigning this one does not
make sense at all.
Policy still documents a relation that is not re
Previously Matthew Palmer wrote:
> Are you contesting 'support' or 'sane'?
Both.
> >From dpkg-1.10.6/ChangeLog:
>
> * dselect/pkgdepcon.cc: treat enhances like suggests in
> packagelist::resolvedepcon()
That's only 15% of the changes that need to be made.
Wichert.
--
Previously Matthew Palmer wrote:
> Since 1.10 is now out and about and (AFAICT) has sane support for Enhances,
> I would suggest that this bug be considered closed.
No, it doesn't.
Wichert.
--
_
/[EMAIL PROTECTED] This
Previously Marcus Brinkmann wrote:
> As for me personally, I have made peace with -O2 code. stepi is your friend
> ;)
Fwiw, debugging C++ code using STL with -O2 is almost impossible.
Wichert.
--
_
/[EMAIL PROTECTED] T
Previously Chris Waters wrote:
> If the merely-functional virtual packages were actually useless (which
> is essentially what you said), then I think we would be justified in
> throwing them out. But I don't think they are, so I don't think we
> are.
Ok. I think we are actually all in agreement n
Previously Mark Brown wrote:
> You also need to know which command to invoke and you need to know when
> it's safe to discard any temporary file you might be pointing at.
The same holds for editor which does have a well defined interface.
Wichert.
--
__
Previously Moshe Zadka wrote:
> www-browser: definitely, here a standard interface (give a URL on the command
> line) is useful. currently, urlview depends on an ugly hack
> to do that (listing browsers itself)
doc-central does the same thing.
> mail-reader: honestly, I
Previously Chris Waters wrote:
> Some virtual packages (mail-transport-agent, c-compiler, httpd, most
> of *-server) clearly do have an associated interface. Some
> (mail-reader, www-browser, audio-mixer) clearly do not.
Lack of an interface tends to be troublesome. Look at doc-central
for exampl
Previously Moshe Zadka wrote:
> Ummm.if a C compiler doesn't support a /usr/bin/cc which supports -o
> and -c, it shouldn't "Provide: c-compiler"
A virtual package is a means to indicate a package provides a certain
interface, not some functionality. Functionality is useless if you
can't use i
Previously Matt Zimmerman wrote:
> The only possible issue that I can see is that the introduction of this
> virtual package would leave no way to depend specifically on the ISC DHCP
> client 2.x, which is currently named dhcp-client.
You could take advantage of the fact that dpkg doesn't support
Previously Julian Gilbey wrote:
> I know that Manoj has been talking about moving to the DocBook DTD for
> the next version of policy. What are people's experiences with it?
I use DocBook for all documents and manpages now and it works great.
> How does it compare to the DebianDoc DTD for what w
Previously Henrique de Moraes Holschuh wrote:
> Oh, quite the opposite. It is *desirable* to have force-reload defined as
> "force a full configuration reload of the service, if it is running. Fail
> otherwise". But the code to do so is more complicated.
I don't see that begin complicated, the
Previously Branden Robinson wrote:
> 2) The examples advise people to redirect the output of update-rc.d to
> /dev/null. Adam Heath and I feel this is a bad idea, and even if this
> change is not made, some people (like the author of lintian; see Bug
> #149700) think that this is normative. To me
Previously Josip Rodin wrote:
> I thought it would do all necessary changes after you said "Yes" on the
> prompt.
It does, but the logic to decide which changes are necessary can handle
options like that (and a few others).
Wichert.
--
_
Previously Jor-el wrote:
> I have seen indications that this is contrary to debian-policy - hence
> my request for revision.
I'll look into revising things on the next base-passwd rewrite which
will be sometime this year.
Wichert.
--
___
Previously Josip Rodin wrote:
> Therein lies the reason why they cannot be simply removed. If you happen to
> install a new base-passwd and have it redo the group file, all the existing
> software on the machine that uses them may break.
I suspect you are not aware of the no-autoremove feature bas
Previously Adam Heath wrote:
> Or, even simpler:
>
> %:
> debian/myrules $@
The unfortunate problem with this is that make has the nasty habit of
changing the exitcode. If myrules exits with a non-zero exitcode you
will see make exiting with a completely different (although still
non-zero)
Package: debian-policy
In version 1.23 of the policy.sgml file Manoj made a few changes
that were related to incorporating the packaging manual into
policy.
Since the packaging manual did not have policy status this should
not have changed anything in policy, certainly not without a clear
consens
Previously Clint Adams wrote:
> Is this important in the event that install-docs gets moved, or so that
> someone can put a different install-docs in the PATH?
Both. Making things more fragile is always a Bad Idea.
Wichert.
--
_
Previously Clint Adams wrote:
> > Such as?
>
> test -x /usr/sbin/install-docs || echo hi
That's different and more fragile: it relies on a fixed path which
command -v does not.
Wichert.
--
_
/[EMAIL PROTECTED] This spac
Previously Richard Braakman wrote:
> I still find it useful to grep and sed the Packages file. I don't
> see any advantage in allowing multi-line fields that would compensate
> for that.
FWIW, dpkg does allow it. Debian policy is free to not allow it of
course.
Wichert.
--
__
Previously Anthony Towns wrote:
> I can assure you I had a lot less time to do stuff like fiddle with the
> BTS when I was trying to get potato released.
And I can assure you I was doing a lot more work on new things while
still working on the potato release than I am doing now.
Wichert.
--
_
Previously Anthony Towns wrote:
> On Mon, May 06, 2002 at 07:17:12PM +0200, Marcus Brinkmann wrote:
> > Debian development is asynchronous.
>
> That's a nice idea in theory.
It just to be true before we had testing.
Wichert.
--
Previously Jeroen Dekkers wrote:
> Debian is more than GNU/Linux. I see no reason why Debian GNU/Hurd and
> Debian *BSD should follow the LSB.
This is a discussion we should be having after the release on a forum
like debian-project.
FWIW, I think we should try to use the LSB as much as possible
Previously Grant Bowman wrote:
> As I've argued late last year [1] Debian should take the necessary
> Policy steps to move forward with LSB adoption.
I agree, but I would like to add we should wait until woody is released.
Wichert.
--
__
Previously Grant Bowman wrote:
> This is somewhat an aside, but this is already moving away from
> GNU/Debian Linux specific through several ports of GNU/Debian. There
> are the hurd, bsd and win32/cygwin ports already.
I have never been able to find patches for the win32/cygwin port though.
I kn
Previously Manoj Srivastava wrote:
> On the other hand, all packages must not be left to the whimsy
> of the dpkg developers either; since potentially large numbers of
> packages would be impacted by such changes.
I do hope you trust is to make changes sensibly. In fact the current
referen
Previously Julian Gilbey wrote:
> Surely either everything necessary should be in the dpkg reference or
> everything necessary should be in policy.
I'm not sure. I see them more as complementing each other, much like
RFC1855 (netiquette) complements RFC822 (email format) or how a
users manual comp
Previously Julian Gilbey wrote:
> Part I: The Debian Archive
> 1: DFSG and the sections of the archive (free, non-free, contrib, non-us)
non-us is a different archive.
> Part II: Packages and metadata
Refer to a dpkg reference instead and document extra restrictions
Wichert.
--
__
Previously Andres Salomon wrote:
> The exact quote from the current policy is:
> "If the package has only one changelog which is used both as the Debian
> changelog and the upstream one because there is no separate upstream
> maintainer then that changelog should usually be installed as
> /usr/shar
Previously Manfred Wassmann wrote:
> I proposed the virtual package foomatic-data on debian-devel on
> 2001-12-11 and filed the bug #123570 against the debian-policy
> package. There have been no objections against my proposal, so I
> consider it to be accepted.
This sounds like it is only going
Previously Jarno Elonen wrote:
> * Many people feel that KDE (and Gnome) is too large
>a whole to be stuffed in /usr/bin, /usr/share etc
>and would deserve a separate directory like X
Define many. I also don't see what the advantage would be of moving
it to a seperate directory. Without k
Package: debian-policy
Version: 3.5.6.0
Severity: normal
In the description of the communication commands the current
text says:
* PURGE
Call this in your postinst when your package is purged.
It removes all templates and questions your package has
generated.
postinst should be replaxed wi
Previously Peter Moulder wrote:
> Please re-read the above paragraph. No-one has claimed that a circular
> dependency is needed.
That's the whole reason for this discussion though..
> They are allowed by dpkg, whereas current policy says that they are not
> allowed, hence giving false confidence
Previously Peter Moulder wrote:
> The thread begins at
> http://lists.debian.org/debian-devel/2001/debian-devel-200112/msg01329.html
> where someone says it would be useful if he could ensure that a
> particular pair of packages' postinst scripts run in a particular order.
I'm not convinced the ci
Previously Anthony DeRobertis wrote:
> The quoted version of policy says that the package must call MAKEDEV. As
> long as this section is being changed, we should probably note that on
> devfs systems, MAKEDEV will turn itself into a no-op.
Why?
Wichert.
--
___
Previously Anthony Towns wrote:
> Things break. That's what happen when things fail. You'll notice we don't
> guarantee anything better for our own init scripts.
LSB does so we will need to start caring. You can't selectively
implement the LSB, that would make the whole thing worthless.
Wichert.
Previously Anthony Towns wrote:
> This doesn't need to be done for Debian packages at all (LSB init script
> dependencies that interact with vendor scripts can all be trivially
> satisfied by doing all the vendor scripts first), and the dependencies
> for the LSB scripts can be resolved at package
Previously Sean 'Shaleh' Perry wrote:
> we can support the installation of lsb binaries HOWEVER the lsb spec adds a
> 'status' option to init scripts which lsb packages may expect to exist. So at
> the bare minimum we need to support that.
At the bare minimum we'll need to support dependencies fo
Previously Daniel Stone wrote:
> Oh, and also bear one thing in mind: the virtual host name (e.g. "foobar"
> in /var/vhosts/foobar) may not have any correlation to the hostname,
> domain, or whatever. So, please don't assume it does.
/var is the wrong place for this. There is a push to move FHS to
Previously Matthew Palmer wrote:
> There is precedent (kind of), g++ uses /usr/include/g++, so why not
> /usr/include/{gnat|ada}?
c++ is a a C derivative, and the FHS explicitly limits /usr/include
to C. If you want to change the FHS bring this up on the fhs-discuss
list first.
Wichert.
--
__
Previously Florian Weimer wrote:
> What about the Ada case? GNAT pretty much requires that complete
> source code is present for all compilation units at compilation (and
> binding/linking) time. And package specs are very similar to C header
> files, at least with the GNAT compilation model.
Qu
Previously Florian Weimer wrote:
> Is it acceptable to put source files for non-C-related languages
> (such as Python, Perl, Ada, Java, and so on) in subdirectories
> under /usr/include?
I'ld say no. Those languages don't use include files, they use
libraries.
Wichert.
--
Previously Brian White wrote:
> I realize that. Any idea when the patch I provide will actually be applied
> to the policy manual? It would be nice to get this underway.
After the woody release I suspect.
Wichert.
--
_
/[EMAIL
Previously Brian White wrote:
> Any idea when the patch I provided will actually be applied to the policy
> manual? It would be nice to get this underway. Thanks!
Policy is frozen.
Wichert.
--
_
/[EMAIL PROTECTED] This
Previously Ian Jackson wrote:
> I'd appreciate it if people wouldn't send messages which are copied to
> *both* the policy list and the technical committee.
Actually the ctte list has seen 1 post this month, all the others
never make it there since the list is moderated.
Wichert.
--
_
Previously Anthony Towns wrote:
> This is daft. Packages should be functional as soon as they're installed, not
> be fundamentally broken and require administrator action.
Agreed.
> Permissions aren't maintained over upgrades, so this will result in
> further breakage
dpkg-statoverride.
>. And
Previously Gerhard Tonn wrote:
> He is not talking about Linux, but a certain flavor of UNIX that is running
> on top of z/OS formerly called OS/390 formerly called MVS.
D'oh, should have noticed that :(
Wichert.
--
_
/ N
I just got this on the vim-dev list. If this is indeed so (strip does
not work on s390) does that mean Debian policy forces us to have
large unstripped binaries on s390?
Wichert.
- Forwarded message from Anthony Giorgio <[EMAIL PROTECTED]> -
From: "Anthony Giorgio" <[EMAIL PROTECTED]>
Previously David Kimdon wrote:
> FWIW that is one thing that e2fsprogs-bf does.
But that has a specific purpose, boot floppies. In the general case
you have no idea what kind of usage you will get.
> I wish a non-invasive approach would solve the problem. However I don't
> think we will arrive at
Previously Richard Braakman wrote:
> - Specific compiler flags (-Os?)
That one would make sense
> - Turning off compile-time options for rarely used features
That's going to be highly controversial
> - No documentation (not even the copyright file?)
> - Installing most-popular subsets o
Previously David Kimdon wrote:
> The purpose of this change is to give Debian a more elegant way of
> handling reduced footprint debs. Rather than including
> special-purpose binaries in the archive (the status quo), I suggest we
> support hooks in source packages that produce size optimized vers
Previously Cesar Eduardo Barros wrote:
> This proposal was not about traceroute. It was about everything else
> (ifconfig,
> route, mke2fs, e2fsck, etc -- everything a normal user runs and yet are at
> sbin). The traceroute thing was just a footnote.
A normal user who runs ifconfig, route or mkfs
Previously Marcus Brinkmann wrote:
> Can you elaborate on the advantage of letting everyone generate their own
> checksums for the installed files? Seems to me a waste of cpu cycles.
We process all the data in a pipe anyway so calculating the checksum
takes no effort. Benefits are we don't need t
Previously Florian Weimer wrote:
> Wouldn't it be nice if each general file management tool
> (command line or text-based or graphical file manager)
> supports 64 bit files (with 64 bit inode values or size
> greater than 2 GB) even on 32 bit architectures?
Sure. Just recompile them with glibc2.2
Previously Massimo Dal Zotto wrote:
> Is this allowed by policy?
Yes.
> And if not should we change the policy and require that every package have
> the .md5sums file?
No. .md5sums are the wrong approach for this. The right approach is
a combination of signing packages themselves, and dpkg gener
Previously Enrique Zanardi wrote:
> Current practice suggests hyphen instead of dot for including a version
> in a package name: mico-2.3.0, kernel-image-2.2.17, cpp-2.95, perl-5.005,
> netscape-smotif-475, libgnat-3.13p-1, libbz2-1.0, libid3-3.7-13, ...
> just to name a few.
Hm, I should have re
Previously Enrique Zanardi wrote:
> On Mon, Jun 11, 2001 at 03:40:29AM +0200, Andreas Bombe wrote:
> > Policy wants shared libraries to be in packages of names like libfoo6
> > for a libfoo.so.6. However this becomes confusing if the library name
> > ends in a number so that the soversion is separ
Previously Loic Dachary wrote:
> I propose that the perl policy includes at least a chapter or
> section titled dh-make-perl so that the existence of this tool is
> obvious just by reading the table of content.
I disagree, policy and tools are seperate things and should not be
mixed. You are
Previously Mike A. Harris wrote:
> We currently AFAIR have all device nodes in a single RPM package
> in RHL, however this may change..
You indeed do.
> Does dpkg et al. have something similar, and if not, would it be
> considered something useful? I can try to get/provide details if
> it would
Previously Anthony Towns wrote:
> --- policy.sgml Fri Jun 1 19:40:16 2001
> +++ policy.sgml.emacstexMon Jun 25 20:58:25 2001
> @@ -764,10 +764,7 @@
> These packages provide a reasonably small but not too
> limited character-mode system. This is what will be
Previously David Martinez CSIC RedIRIS wrote:
> Well, I'd propose to make an addition to Policy and/or NM Guide:
I propose to ignore this until Adam unveils the dpkg-source he is
working on which will make this point moot.
Wichert.
--
Previously Herbert Xu wrote:
> Florian Weimer <[EMAIL PROTECTED]> wrote:
> > and neither is libc6 because some parts of it can only be linked
> > statically.
>
> Which ones?
nss modules come to mind.
Wichert.
--
_
/ Nothi
Previously Jaldhar H. Vyas wrote:
> However according to /usr/lib/dpkg/parsechangelog/debian, the acceptable
> values for urgency are:
And that list isn't correct either iirc.
> This change seems to have happened around dpkg 1.9 but isn't in the
> changelog.
That's because that list was never th
Previously Julian Gilbey wrote:
> Wichert, Anthony, any chance of resolving this one soon?
For what value of `soon'? Given that noone has noticed that even
though this inconsistency has been there for years means it's
not very high on my todo-list. We'll get around to it before
a 1.10 release thou
Previously Julian Gilbey wrote:
> This inconsistency has only been relevant since testing came into
> being.
Which is months ago now and still nobody noticed, probably since
the priorities for testing were never documented.
Wichert.
--
_
Previously Adrian Bunk wrote:
> It seems he's right and I can't find a place in the policy that forbids
> the deletion of old changelog entries or did I miss something?
It also doesn't allow it. Common behaviour seems to be to move the old
changelog entries in a seperate file.
Old changelog entri
Previously Julian Gilbey wrote:
> The CVS version no longer has the part "though currently ..." as this
> is not currently true.
That default will never change in the dpkg code anymore as well, instead
the installer will have to put that in /etc/dpkg/dpkg.cfg.
Wichert.
--
___
Previously Manoj Srivastava wrote:
> Well, 4.5 years is a long time, but I suspect that
> sensible-editor mechanism was supposed to be the way to go. Since
> packages already manipulate the sensible editor link, and there
> always is supposed to be one, perhaps t was thought that editor
>
Previously Josip Rodin wrote:
> Well, because it's useless? A vast majority of packages depend on an editor,
> anyway.
I don't see why it's useless.
Wichert.
--
/ Generally uninteresting signature - ignore at your convenience
Previously Josip Rodin wrote:
> 25 Nov 1996 Removed editor (should have done this a long time ago)
Does anyone remember the rationale for that?
Wichert.
--
/ Generally uninteresting signature - ignore at your convenience \
Previously Daniel Kobras wrote:
> For now I added a lintian overrides for this, but Sean asked me to bring up
> discussion here to clarify what lintian should treat as shared lib in the
> future in order to properly solve this issue.
Geez, again? Basically a .so files that is not in /lib, /usr/lib
Previously Henrique M Holschuh wrote:
> The package diverts the outdated files /usr/share/automake/config.
> {guess,sub} and /usr/share/libtool/config.{guess,sub}, and supplies
> up-to-date files from CVS (there is a 2001-04-20 update supporting sparcv9b
> for example) in their place.
I doubt that
Previously Julian Gilbey wrote:
> 11.2, penultimate paragraph reads:
> Packages that use libtool to create shared libraries should
> include the _.la_ files in the _-dev_ packages, with the
> exception that if the package relies on libtool's _libltdl_
> library, in which case th
Previously Cyrille Chepelov wrote:
> Dependencies and Build-Dependencies can be quite long, which means either
> using a lot of horizontal scrolling, or violating the policy (since lintian
> checks for single-lineness of some fields but not those, and dpkg is happy
> with that, and the buildds too
Previously Cyrille Chepelov wrote:
> I think it would be very useful if DebPol section 3.2 began with an
> informative table of all fields which can happen in a debian/control file,
> with links to the relevant (normative) section for details, a very short
> description of the kind of data
I alr
Previously Cyrille Chepelov wrote:
> I've got an interpretation problem: can relationship fields be written
> on multiple lines ?
Looking at the dpkg parsing code, yes. Which makes sense, considering
we are dealing with RFC822 syntax.
Wichert.
--
___
Previously Julian Gilbey wrote:
> Agreed. I presume that ldconfig exists on all systems, though.
All systems Debian currently runs on anyway. I kind of expect that to
change at some point though.
> Please explain; I don't know what you mean here.
I'll have to get back to you on that :)
> Are w
Previously Anthony Towns wrote:
> Seems like either fakeroot could be enhanced to handle that, or maybe
> such packages should be restricted to being built with sudo with the
> appropriate checks in debian/rules to ensure that either the user already
> exists, or that running adduser in debian/rule
Previously Julian Gilbey wrote:
> But what does it mean for a "suggests to take effect"?
(Pre-)Depends, Conflicts and Replaces are the only ones that dpkg
cares about, the others are for frontends like dselect. A Suggests
can't really take affect.
>
> > > 7.2 Depends: should also mention "or if
Previously Anthony Towns wrote:
> What's special about dynamic u/gids? You just make sure the user/group
> exists in the preinst, then let dpkg unpack it to the correct id. No need
> for statoverrides at all.
The name of the user/group must be used in the data.tar.gz, which can
only happen if the
Previously Julian Gilbey wrote:
> 7.2 Binary dependencies
> This section states that "All but Pre-Depends and Conflicts take
> effect only when a package is to be configured." But actually,
> dpkg appears to ignore everything except for (Pre-)Depends,
> (sometimes) Recommends and C
1 - 100 of 429 matches
Mail list logo
