Or the script could simply test and run like the init.d scripts do.
On 09-May-99 Karl M. Hegbloom wrote:
>
> What if a package is installed, and puts a script in a run-parts
> directory or into a .d directory, but isn't configured due to a
> missing dependancy? The newbie "sysadmin" doesn't know
On 12-Jul-99 [EMAIL PROTECTED] wrote:
>
> Note that having the current kernel header files installed in
> /usr/include/linux is critical to be able to compile source distribution
> of stand-alone modules --- i.e., for the Comtrol Rocketport, the PCMCIA
> drivers, the stand-alone serial driver, et
>
> If we also went back to the old days of the kernel-source packages
> unpacking into /usr/src/linux/, I would be pretty darned happy.
>
You have my vote here. kernel-source- -> linux was nice. This going in
and untarring is not a pretty as debian could be.
Joeyh has *NOT* modified debhelper. This is a conscious decision, not slacking.
He states that he will change it when policy has decided what the right thing
is. Until then debhelper stands as is.
Provided we rotate items into an obsolete/ directory, then remove them so as to
let possible new maintainers take them I am behind this.
Allowing new Debian developers a chance to help out older packages is a great
way to allow them to look at work that has been done already.
This seems reasonable. I already do this w/ pop3 (pop-server).
Consider this a second.
Shaleh
oidentd maintainer
>
> So what you're telling me is that anyone with a "complex" setup
> shouldn't bother using Debian?
>
a) I would not test a new daemon on a working machine, I would use a separate
one. In the case of gnu pop3, it will spin off and consume 99% of your cpu due
to poor child management. We (I am
On 27-Sep-99 Clint Adams wrote:
>> a) I would not test a new daemon on a working machine, I would use a
>> separate
>
> So?
>
>> b) if you know what you are doing, compile the packages by hand, fix their
>> install scripts, and remove the conflicts. You are trying to circumvent the
>> norm.
>
Ok, let's bring this back to implementation. How would you propose we handle
this? Currently daemons install, set themselves up, and begin running.
a) we can prompt.
b) we leave everything off and let the admin turn it on (not an option for
obvious reasons)
c) first come first serve -- first dae
On 29-Sep-99 Anthony Towns wrote:
> On Wed, Sep 29, 1999 at 11:05:50AM +0100, Edward Betts wrote:
>> Michael Alan Dorman <[EMAIL PROTECTED]> wrote:
>> > I really think it's a bad idea to have versioned -dev packages. Have
>> > we really had instances where they have given us any real advantage?
>
>
> e) Let update-inetd handle this. This might not be enough for standalone
> servers like apache and roxen but it would work with a pop3 server -
> update-inetd -add should notice that there is already a valid entry enable
> with that service and add the new entry with a hash mark.
>
Not enoug
>
> It sounds like ICCCM is far too restrictive, and should be relaxed...
>
The originial idea was that a second wm spec would appear. But it never did.
There is now work going on with all major wm authors, GNOME, and KDE, as well
as Jim Gettys to work on a new wm spec as an add on to ICCCM.
On 04-Dec-1999 Branden Robinson wrote:
> On Sat, Dec 04, 1999 at 03:28:18AM +0200, Antti-Juhani Kaijanaho wrote:
>> On Fri, Dec 03, 1999 at 03:56:35PM -0800, Joey Hess wrote:
>> > + Every package must have exactly one maintainer at a time. The
>> > + maintainer may be a mailing list.
>>
On 08-Jul-2000 Joey Hess wrote:
> Package: debian-policy
> Severity: wishlist
>
> There has been some discussion lately on debian-deval (and a bit on
> -policy) about init scripts. One concern that has arisen is that it can
> be very annoying to have to modify an init script to change a simple
>
On 18-Jul-2000 Adrian Bridgett wrote:
> Debian policy says:
> 4.6. Device files
> -
> No package may include device files in the package file tree.
>
> If a package needs any special device files that are not included in the
> base system, it has to call `makedev' in the `postinst
>
> Good point, but it's still a question. In fact adding debconf support
> raises the interesting question - what severity should the question be -
> critical?
>
> The package I'm maintaining (tpctl) adds /dev/thinkpad (root.root
> 0660) and so "low" would seem more appropriate - in fact not as
> I was hoping to avoid this, but developing consensus on -policy seems to be
> that I should do this. Sigh.
>
>> [1] Verified, that is lib/Xt/Initialize.c, XtScreenDatabase()
>
> I'm not sure it's not the only one. It's not just Xt-using apps that read
> app-defaults, IIRC. I think the Xrm* f
4.7.4 Sharing configuration files
Packages that are not tagged as conflicting with each other must not specify
the same file as conffile.
This is very poorly worded. The text used to read -
Only packages that are tagged *conflicting* with each other may specify the same
file as `conffile'.
>
> FWIW I understood them both just fine. I think it was changed because "may"
> and "must" have explicit meanings now...
>
It is rather close to reading as a double negative.
>
> Or what about:
>
> Packages which specify the same file as `conffile' must be tagged as
> *conflicting* with each other.
>
>
> Which loses the double-negative, and retains the strong _must_ without
> becoming impenetrable.
>
I like this text. Perhaps it should read "file as a 'conffile'"
On 29-Sep-2000 Wichert Akkerman wrote:
> Previously Sean 'Shaleh' Perry wrote:
>> Current issues:
>> the whole "your library has no shlibs file" thing. Once a policy has been
>> approved for packages with dynamically loaded modules lintian will be
>
On 29-Sep-2000 Josip Rodin wrote:
> On Fri, Sep 29, 2000 at 03:40:25PM -0700, Sean 'Shaleh' Perry wrote:
>> >> the whole "your library has no shlibs file" thing. Once a policy has
>> >> been
>> >> approved for packages with dynamical
packaging manual is a little unclear. When do I call ldconfig? It is clear
that I should call it only for the configure case in my postinst script. But
do I call it at all in my pre/postrm scripts? The manual simply says to be
sure not to call it for the upgrade case.
>
> The sorts of information which currently get displayed, but which don't
> get prompted for, are things like "Restarting internet superserver:
> inetd", or "Updating /etc/network/interfaces: succeeded".
>
> To me, those sorts of outputs seem useful and helpful, so I think policy
> should proba
>
> This would require lots of changes to packages.
>
so we change lots of packages. Debian is being used by IS more and more these
days. At VA alone we have some 100+ Debian machines now. The current package
setup makes this a headache for updates. Being able to log output and ensure
that t
On 22-Nov-2000 Wichert Akkerman wrote:
> Previously Chris Waters wrote:
>> I think Wichert was wrong in this case. I don't think policy should
>> be in charge of every minor feature of the toolkit, especially not
>> optional features.
>
> How many times do I have to repeat that this is *NOT* a f
On 29-Nov-2000 Wichert Akkerman wrote:
> Package: debian-policy
>
> RMS just asked me if it was true that all our packages don't include
> the GPL, just a reference to it, since that is a violation of the
> GPL itself. In his words:
>
we do not remove the copyright. it is still in the source.
>
> Lots of packages include the generic GNU install instructions, nobody uses
> them because they have installed a Debian package, but lots of packages
> include them.
>
I would file a bug whenever I found that to be true.
On 29-Nov-2000 Wichert Akkerman wrote:
> Previously Sean 'Shaleh' Perry wrote:
>> we do not remove the copyright. it is still in the source. I fail to see
>> why
>> having 300 copies of the same file is needed.
>
> Reread my mail. Then realize that the GPL
On 29-Nov-2000 Ben Collins wrote:
> I'm proposing we add a new field to generated packages, and as part of
> Debian policy, make them required for Debian packages. It's all very
> simple, doesn't requuire any effort by the maintainers other than
> upgrading dpkg-dev, and poses little side-affects
> Your UUID is the pkg+version+arch. From my viewpoint it's as simple as
> that. Maybe the official policy needs to be updated so that it is clear
> that any change to the binary packages, including just compile time changes,
> requires a version update? That way you could change your "sigs" as
>
> Sorry, I'm not a Debian developer so honestly don't know all the policies or
> processes behind making debs. But, it seems clear to me that if you use the
> pkg+version+arch as your UUID then a change in the md5sum caused by adding a
> signature would not effect the "UUID" and therefore be mo
>
> Good grief. This would require all non-rsync mirrors to redownload *ever*
> .deb in the newly released distribution in whole, and would require
> every user to redownload every package they've installed if they want to
> upgrade from foo-unstable to foo-stable. It'd also mean package signature
>
> So you think it's easy to force users to generate a unique version number?
> How are you going to do that? If you make a debian developer pass a
> special arg, how are you going to keep users from using the same thing?
>
> Obviously it's not so easy, or it would already be done.
>
beyond th
Package: debian-policy
Version: 3.2.1.0
Severity: normal
preinst scripts are not mentioned anywhere in policy and should be.
-- System Information
Debian Release: woody
Architecture: i386
Kernel: Linux geisha 2.2.18pre11 #1 SMP Mon Oct 2 17:40:32 PDT 2000 i686
Versions of packages debian-policy
On Sat, Dec 23, 2000 at 03:25:41PM +1000, Anthony Towns wrote:
> On Fri, Dec 22, 2000 at 02:02:01PM -0800, Sean 'Shaleh' Perry wrote:
> > Package: debian-policy
> > Version: 3.2.1.0
> > Severity: normal
> >
> > preinst scripts are not mentioned anywhere
I was of the understanding that we would also have to notify the US of what is
on our site.
>
>> Since lintian reports the absence of a manpage as an error, maintainers
>> (specially new maintainer) proceed to install a link pointing to
>> undocumented.7 instead of actually providing a manpage.
>
> The previous lintian maintainer was considering the idea of making the
> use of undo
>
> (Good thing I just happened to have a package that uses undocumented.7
> lying around, eh? :-)
>
> Anyway, except for the additional info on the new tag, it's a one-line
> patch, so it should be pretty easy to add.
>
please see the BTS, Colin submitted a full patch plus testset. (Which is h
lintian currently emits a tag for cross-compilers because they make a directory
in /usr's top level for TARGET i.e. /usr/m68k-linux.
The FHS states:
No large software packages should use a direct subdirectory under the
/usr hierarchy. An exception is made for the X Window System because of
consi
Package: debian-policy
Version: 3.5.0.0
Severity: minor
footnotes.html:Having a separate package allows one to nistall
^^^
should be install
-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux geisha 2
Package: debian-policy
Version: 3.5.0.0
Severity: minor
telent-client Any package that provides a telnet client
telent-server Any package that provides a telnet server
in both cases it should read telnet.
As an aside, it would be REAL nice if this list could be moved to a mac
>
> Anyway, I was wondering if this is something we want to discourage in
> policy, or if I'm just not thinking the same way as most maintainers
> (i.e. my premises are flawed).
>
>
as you say in this and later messages on the thread, it is important that
Debian have a way of knowing how buggy
Package: debian-policy
Version: 3.5.0.0
Severity: normal
3.1:
When writing the control files for Debian packages you must read the Debian
policy manual in conjunction with the details below and the list of fields for
the particular file.
-- end quote
'must read the Debian policy manual', but I
Package: debian-policy
Version: 3.5.0.0
Severity: normal
3.2.1:
The use lowercase package names is strongly recommended
--end quote
perhaps an 'of' should be added?
-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux geisha 2.2.18pre11 #1 SMP Mon Oct 2 17:40:3
Package: debian-policy
Version: 3.5.0.0
Severity: minor
Chapter 4:
upstream-version
It is usually version number of the original (`upstream') package of which the
.deb file has been made, if this is applicable.
-- end quote
a) between usually and version a 'the' should be added
b) 'of which' sho
Package: debian-policy
Version: 3.5.0.0
Severity: minor
5.2
Since an interactive debian/rules script makes it impossible to auto-compile
that package and also makes it hard for other people to reproduce the same
binary package, all required targets MUST be non-interactive. At a minimum,
required t
Package: debian-policy
Version: 3.5.0.0
Severity: minor
5.2
It is important to understand that the DEB_*_ARCH string does only determine
which Debian architecture we build on resp. for.
-- end quote
The English of this sentence is very poor. 'does only determine' and expecially
'we build on resp.
Package: debian-policy
Version: 3.5.0.0
Severity: minor
6.1
They should be readable and executable to anyone, and not world-writable.
the package management system looks at the exit status from these scripts.
-- end quote
The second sentence should begin with a capital letter.
-- System Inform
Package: debian-policy
Version: 3.5.0.0
Severity: minor
6.5
In each case if an error occurs the actions in are general run backwards
-- end quote
not sure what the author meant here. I suspect 'in are' is transposed and
should 'are in'.
-- System Information
Debian Release: testing/unstable
Arc
Package: debian-policy
Version: 3.5.0.0
Severity: minor
-- quote
If a version the package is already installed, call
-- end quote
seems to be missing an 'of'.
-- quote
A directory will never be replaced by a symbolic links
-- end quote
links should singular
--quote
Any packages all of whose fil
On Sun, Feb 11, 2001 at 01:38:53PM +1000, Anthony Towns wrote:
>
> "Starting internet superserver: inetd" doesn't seem like vitally important
> information, nor something worth having a "[Press enter to continue]" for.
> OTOH, it still seems worth printing, as discussed some time ago.
>
> This se
Package: debian-policy
Version: 3.5.0.0
Severity: minor
-- quote
saying that they require certain binary packages being installed
-- end quote
I think this should read 'having been installed'. Present, future and past
are being blurred in that sentence.
-- quote
the fields which declare dependen
Package: debian-policy
Version: 3.5.0.0
Severity: minor
-- quote
Usually this is major version number of the library.
-- end quote
'the major'.
-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux geisha 2.2.18pre11 #1 SMP Mon Oct 2 17:40:32 PDT 2000 i686
Versi
Package: debian-policy
Version: 3.5.0.0
Severity: minor
-- quote
It should place a file with the name if the package
-- end quote
'if the' should be 'of the'.
-- quote
In the example above the system administrator can easily comment out a line
if he don't wants to start a specific daemon,
-- end
Package: debian-policy
Version: 3.5.0.0
Severity: minor
-- quote
but are also useful as standalone documentation should be installed under
/usr/share/
bug #71581 asks that lintian complain about packages that fail to ship .la
files as policy 11.2 requires. I am not against this per se.
However, how am I to know that a package should ship a .la file? When policy
refers to libs needing libltdl does it mean they dynamically link it? So I
could u
I would greatly appreciate it if some of you would read the lintian bug list
and supply comments, either in favor of the suggestions or against. Some of
the open bugs need policy updates to fully fix in my opinion.
Also, now is the time to submit your own lintian requests and bugs. I am
preparin
On Sun, Feb 18, 2001 at 03:34:35AM +0100, Peter Palfrader wrote:
> | 2.4.2. Package relationships
> |
> |
> | Source packages should specify which binary packages they require to
>^^
> | be installed or not to be installed in order
Anyone have comments on the idea that the only packages we should release are
ones that have a maintainer, not Debian QA?
So, I grabbed fmirror today because an admin friend suggested it. I cd'ed to
/usr/share/doc/fmirror and low and behold, no /usr/share/doc/fmirror. I check
the changelog and this binary-any package has not been uploaded in 2 years. It
is standards version 2.3.0.1, ICK!
So, perhaps we should drop
On 20-Feb-2001 Seth Arnold wrote:
> * Sean 'Shaleh' Perry <[EMAIL PROTECTED]> [010220 10:39]:
>> Anyone have comments on the idea that the only packages we should release
>> are
>> ones that have a maintainer, not Debian QA?
>
> In taking a quick list
On 20-Feb-2001 Matthew Vernon wrote:
> Sean 'Shaleh' Perry writes:
> > Anyone have comments on the idea that the only packages we should release
> are
> > ones that have a maintainer, not Debian QA?
>
> How about asking the QA team? I think that "packages
>
> And more serious: If you want to force the upgrade of the standards
> version you must file 579 RC bugs on these packages.
>
sounds like a plan to me. Many of these are either:
a) horribly out of date
b) simply forgot to change the number
On 20-Feb-2001 Sean 'Shaleh' Perry wrote:
> So, I grabbed fmirror today because an admin friend suggested it. I cd'ed to
> /usr/share/doc/fmirror and low and behold, no /usr/share/doc/fmirror. I
> check
> the changelog and this binary-any package has not been uplo
On Wed, Feb 21, 2001 at 11:30:23AM +1000, Anthony Towns wrote:
>
> I'd encourage the lintian maintainer ( :) ) to automatically file "old
> standards version" bugs about such packages (of normal/minor/wishlist
> severity); and I'd definitely encourage the lintian maintainer to file
> serious bugs
On Wed, Feb 21, 2001 at 12:39:08PM +1000, Anthony Towns wrote:
>
> > > E!: non-FHS-directory
> > > E-: missing-manpage
> > > E?: standards-version-uses-4-digits-not-3
> > when I rewrite lintian (started yesterday) the lintian messages will match
> > policy:
> > Error (E:) -- violate a MUST
>
>>
>> no, it tries to do this based on 2.x level MUST/SHOULD and the authors
>> beliefs
>> of severity. Has nothing to do with the sureness of the test.
>
> When did this change, then? Christian and I designed it the way Anthony
> described it.
>
Gecko did some, new checks added between him a
On 21-Feb-2001 Bob Hilliard wrote:
> "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> writes:
>
>> Error (E:) -- violate a MUST
>> Warning (W:) -- violate a SHOULD
>> XXX (?:) -- a MAY is not followed
>
> There should be no Linti
I can not find anything in the checklist about Build-Depends. I have been told
it was 3.2.x, is this accurate?
Package: debian-policy
Version: 3.5.2.0
Severity: normal
please refer to lintian bug 86710, it asks for lintian to check the syntax of
the Build-Depends field.
Specifically, [!i386 m68k] seems like it could be valid, but seems to not be.
The archs are also whitespace separated, some people are us
Since suidregister was removed, packages are now allowed to ship items with the
set[gs]id flag on. This is currently a lintian warning. I have considered
removing it (and bugs ask me to do so) however I am not sure it is the right
thing to do. The warning lets the developer know that they are sh
There has not been a consensus on several issues I have raised here:
what to do about cross-compiler directories? Do they belong in /usr/${arch}?
what to do about shared objects that are not meant to be linked against, i.e.
plugins?
libtool .la files, how can lintian handle this well?
also, I
On 27-Feb-2001 Josip Rodin wrote:
> On Tue, Feb 27, 2001 at 10:21:44AM -0800, Sean 'Shaleh' Perry wrote:
>> what to do about shared objects that are not meant to be linked against,
>> i.e.
>> plugins?
>
> If a .so is not meant to be linked against and is not
>>
> Clarification here. Since libtool is Priority: optional... shouldn't
> packages that use it Build-depend on it? If so you can use that to
> determine libtool was used, therefore .la files should be shipped as
> well?
interesting ..
>
> I would like to propose that the debian/rules file is allowed to be
> non-makefile. Any kind of a program that can do the required stuff can be a
> debian/rules file. We shouldn't prohibit it when someone e.g. writes a short
> shell script or another interpreted script, as long as it works.
>
On 28-Feb-2001 Julian Gilbey wrote:
> On Sun, 25 Feb 2001, Julian Gilbey wrote:
>
>> Package: debian-policy
>> Version: 3.5.2.0
>> Severity: wishlist
>>
>> Policy should now require packages to specify build time dependencies
>> (i.e., packages which require ... MUST specify...)
>
> I just chec
On Tue, Mar 06, 2001 at 10:38:53PM +, Colin Watson wrote:
>
> So - reassigning the lintian bug about this to policy.
>
> Am I right in taking from the above that /usr/${arch} is essentially a
> miniature mirror of the /usr filesystem? They certainly seem to have
> similar structures. Thus, /u
On 07-Mar-2001 Ben Collins wrote:
> On Wed, Mar 07, 2001 at 06:14:08PM +0100, Othmar Pasteka wrote:
>> hi,
>>
>> while packaging modlogan i have to use overrides because modlogan
>> uses shared objects for its plugin system which are not shared
>> libs. but since there has to be a shlibs file for
I just received a bug because lintian does not know about the section
'science'. Where is the canonical list of sections?
On 26-Mar-2001 Antti-Juhani Kaijanaho wrote:
> On 20010326T112130-0800, Sean 'Shaleh' Perry wrote:
>> I just received a bug because lintian does not know about the section
>> 'science'. Where is the canonical list of sections?
>
> Basically, the set
> What do people think of this idea? The only change it will require in
> policy is specifying "FHS version 2.1" in place of "FHS" when we
> discuss it. (Exact diff will be supplied if needed.)
>
We should definately document the version of any policy we follow -- LSB, FHS,
etc.
Do you have an
On 11-Apr-2001 Julian Gilbey wrote:
> We don't really have any standard way of saying "you really should do
> this as it's a really good thing to do, but there's no requirement to
> do so (and hence not a reason to file bug reports)".
>
I thought we were using RFC definitions of must and should,
On Sat, Apr 14, 2001 at 05:29:20PM +0200, Daniel Kobras wrote:
>
> I have prepared a package of libdv, a library to de- and encode digital
> video data, and noted that it violates current policy: The x86 version
> of the library contains optimized assembler routines that are not
> relocatable. The
On Sat, Apr 14, 2001 at 07:49:32PM +0200, Daniel Kobras wrote:
> On Sat, Apr 14, 2001 at 10:28:57AM -0700, Sean 'Shaleh' Perry wrote:
> > I maintain libnet this way, it only ships as a static lib. So I have a
> > libnet0-dev package. Someday I hope to have a s
I was recently mailed about lintian failing on UPX compressed binaries in
packages. UPX is a way to compress binaries on x86 machines in such a way that
they are self decompressing -- i.e. it is transparent to the user.
However, compressed binaries have their own issues. The binary will not be
s
On Sat, Apr 21, 2001 at 04:44:24PM -0400, Bob Hilliard wrote:
> gcc apparently creates sections `.note' and `.comment' when compiling
> binaries. Running either `strip' or the -s option to install does not
> remove these redundant sections. Lintian issues a warning
> `binary-has-unneeded-sec
On Sun, Apr 22, 2001 at 12:11:12AM +0300, Richard Braakman wrote:
>
> Rules files rarely call strip directly, and when they do it
> is uncomfortable to add the long options for stripping those
> two sections. It doesn't makes much difference whether 99%
> or 100% of the binaries strip them, becau
On Sat, Apr 21, 2001 at 06:47:08PM -0400, Itai Zukerman wrote:
> On Sat, 21 Apr 2001 13:36:36 -0700, Sean 'Shaleh' Perry <[EMAIL PROTECTED]>
> wrote:
> > I was recently mailed about lintian failing on UPX compressed binaries in
> > packages.
>
> How does
On Sun, Apr 22, 2001 at 07:08:14PM +1000, Herbert Xu wrote:
> Richard Braakman <[EMAIL PROTECTED]> wrote:
> > On Sat, Apr 21, 2001 at 05:03:34PM -0700, Sean 'Shaleh' Perry wrote:
> >> It was elevated to see just how many people this affected. Almost no one
>
> Ain't gonna happen. It's been discussed before. The problem is that most
> debhelper Build-Depends actually need to be versioned[1], which won't
> work with build-essential.
>
problem is when following unstable, one sometimes has debhelper depends change
fairly often. No sense forcing the buil
> Bottom line, I think the short-term arguments against making debhelper
> build-essential are decent, but long-term is another matter.
>
my understanding of build-essential is that the package gives people an easy
way to have a system capable of compiling a C(++) program. There is nothing in
it
>
> I'd prefer if people seconded the diff in #66023 :) and then we can refine
> that stuff further if necessary.
>
agreed, let's get this solved.
(Seconded).
On 07-May-2001 Julian Gilbey wrote:
> Most init.d scripts are expected to support all of start, stop,
> etc. options. But there are a small number of scripts which are
> obvious exceptions to this rule: restart, reboot, single, mountall.sh
> and so on.
>
> It would be really nice to have a parag
On 10-May-2001 Chris Waters wrote:
> I'd like to remind people that Menu policy says that icon images
> used in the Debian menu system should be no larger than 32x32.
> Unfortunately, people seem to be sticking in any old image they can
> find, these days.
>
> I've filed a couple of bug reports a
> Does this change have a rationale (and if so, could it be included in a
> footnote), or should it be reverted?
>
The file is expected to be changed, which would trigger the 'get the new
version?' prompt. Trying to reduce those prompts seems like a good idea.
Not sure if that is the rationale
> I disagree with this proposal on a number of grounds:
>
> 1) There is more than one implementation of libGL available in Debian;
> bumping one to standard would require choosing one.
> 2) If Xlib is optional, I would be hard pressed to believe that libGL
> should be standard.
> 3) Surely we can
>
> It concerns the fact that MAKEDEV is called from the postinst to create
> the required ISDN devices, without first asking the user for permission.
>
It does seem a bit odd. Most packages seem to ignore that piece of policy.
Only plausible rationale would be the "sysadmins are cranky and wa
> I'd much rather go with the maintainers' judgements than lintian's.
seeing as lintian is a rather stupid perl script and the maintainer isn't this
seems like a good bet (-:
1 - 100 of 124 matches
Mail list logo
