Re: Bad version number based on date advice in policy?
Josip Rodin [EMAIL PROTECTED] wrote:
Hiding epochs actually has adverse effects (I've seen several dependencies
get broken because the epoch was forgotten), so that's not a particularly
happy feature...
Point taken. However, the alternatives to epochs can also be error-prone
since they deviate from the actual upstream version number.
The policy should discuss this in any event, and then the developer can
make a decision depending on their circumstances.
Sure, as long as the discussion does not involve any prejudice against
using epochs.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Bad version number based on date advice in policy?
Peter S Galbraith [EMAIL PROTECTED] wrote:
Wouter Verhelst [EMAIL PROTECTED] wrote:
On Wed, Nov 26, 2003 at 09:49:38PM -0500, Peter S Galbraith wrote:
[policy 3.1.2]
I would suggest using 0.MMDD to avoid using epoch when upstream
finally decides to use version 1.0 instead.
What's wrong with using an epoch?
Most people would prefer not use them if they can avoid it.
I suppose they are rather ugly and they need to be explained to people
outside of Debian.
And somehow 0.MMDD is more elegant or requires less explanation?
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Bad version number based on date advice in policy?
Peter S Galbraith [EMAIL PROTECTED] wrote:
And somehow 0.MMDD is more elegant or requires less explanation?
Absolutely. It's _one_ number, and people can easily understand it's
less than unity. (A lot of upstream versions numbers that have dates
have them because upstream doesn't feel the software to be ready to be
called 1.0)
I won't start a discussion of whether 1:1.0 can be treated as a number
or not :)
However, epochs are designed so that they only need to be shown where
it is necessary to establish the aboslute order between two arbitrary
version numbers.
That is, in any context where such comparisons are not necessary, it
is permissible for the epoch to be hidden. In fact, some of our tools
already do that. For example, you won't find any epochs in the filenames
in the archive pool. This applies equally to most interfaces with the
user. Unfortunately not all the tools today hide the epoch in every
place where it is possible, but that is something that can be addressed.
On the otherhand, any attempt to avoid an epoch results in a
mutilation of the version number that is at least as horrific.
Worse yet, such a mutilation cannot be hidden from the user
systematically.
Some may argue that such mutilations are only temporary. Well I must
say that in the contexts that I've seen it used, it is not obvious
that their existence over the lifetime of a package will be
significantly less compared to the that of an epoch if it were used.
In this particular instance, it is not obvious whether a package
will spend most of its life as MMDD or X.Y until that switch
has been made.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#218530: Suboptimal conditional rune for initscripts
Ian Jackson [EMAIL PROTECTED] wrote:
This would be better expressed as
if type -p invoke-rc.d /dev/null 21; then
...
This latter form will detect accurately whether invoke-rc.d is
available _on the current PATH_ as set by the sysadmin, and will
therefore allow somewhat greater flexibility to admins (eg, to install
invoke-rc.d separately in /usr/local before upgrading).
You'd better make that simply type so that it will work with
POSIX shells other than bash. Besides, there is no reason to
rule out aliases/functions/builtins since when invoke-rc.d is
actually run those things will all be considered by the shell.
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Colons in upstream version.
Richard Braakman [EMAIL PROTECTED] wrote:
This just means that colons are _sometimes_ allowed in the upstream
version (namely when the package already has an epoch for some reason).
No they're always allowed. You just have to prefix them with an epoch.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#203650: Poor recommendation in dpkg-statoverride section
On Mon, Aug 04, 2003 at 11:05:54AM -0500, Adam Heath wrote:
You also need to ensure that adduser and anything that it depends on to
function are always available at all times just like libc6.
You're confusing pre-depends and essentialness.
What about the case if adduser needs a new feature in useradd and
thus uses a versioned dependency on passwd. This means that the
new adduser can be unpacked before the new passwd is unpacked or
configured since it's only a plain old dependency.
As an unversioned pre-dependency is fulfilled as long as a
package was previously configured, this will allow packages declaring
pre-dependencies on adduser to run their preinsts even though
the new passwd is not yet available, rendering adduser useless.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#203650: Poor recommendation in dpkg-statoverride section
On Sun, Aug 03, 2003 at 10:23:10PM +0200, Jakob Bohm wrote:
Also, careful examination of the adduser implementation in
woody indicates that the package really only needs its
dependencies to be unpacked, at least to add system users and
groups. The configure steps of adduser, passwd, and perl-base
apparently only change things not affecting that particular
operation.
Can you really guarantee that this will be the case in future?
Remember when perl broke during the libdb upgrade?
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#203650: Poor recommendation in dpkg-statoverride section
Andrew Suffield [EMAIL PROTECTED] wrote:
And appending this text to section 10.9:
If you want files in a package to be owned by a dynamically allocated
user or group, then you should create the user or group in preinst, so
that it is present when the package is unpacked.
Objection. There is no way to create any user in preinst as the tool
to do so is not in an essential package.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#203650: Poor recommendation in dpkg-statoverride section
Adam Heath [EMAIL PROTECTED] wrote:
Objection. There is no way to create any user in preinst as the tool
to do so is not in an essential package.
This is what pre-depends are for.
A single pre-dependency is not enough. You will need to convert all
of adduser's dependencies into pre-dependencies, and probably most of
the things it depends on as well.
You also need to ensure that adduser and anything that it depends on to
function are always available at all times just like libc6.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#190749: debian-policy: /etc/init.d scripts example 'test -f program-executed-later-in-script' should be 'test -x'
Pierre THIERRY [EMAIL PROTECTED] wrote:
[-- text/plain, encoding quoted-printable, 35 lines --]
Package: debian-policy
Version: 3.5.6.1
Severity: minor
Tags: patch
In the 10.3.2 section, a example line to test if the program to execute
does exist is given, but it only tests if the file exists, not if it is
executable.
There is no point in test executability since the test is meant to
determine whether the package has been removed or not.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: POSIX shell clarification
Decklin Foster [EMAIL PROTECTED] wrote:
(I'm not sure where to send this, but it's of interest for making
packages containing shell scripts policy-compliant, which I'm currently
trying to do, so...)
bash and dash differ in their handling of variable assignments. To wit:
bash$ FOO=$(false) || echo failed
failed
dash$ FOO=$(false) echo worked
worked
This is definitely a (recent) bug in dash.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: POSIX shell clarification
On Sun, Dec 22, 2002 at 07:34:03PM -0500, Decklin Foster wrote:
Thanks. Could you point me to where the correct behavior is specified?
Penultimate sentence before section 2.9.1.1.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Bug#171221: openmotif: openmotif is not a native package
reopen 171221
quit
On Sat, Nov 30, 2002 at 05:24:58PM +0100, Gerd Knorr wrote:
should or must? I can't find anything in the policy saying
I *must* package it this way, it just says it is usually done this
way. Thus I hereby close that bug.
It is specified in C.3.
I didn't modify the upstream tarball btw. It is as-is within the
uploaded tarball, together with patches and other files I need to
build the debs.
Perhaps the general opinion on this has changed. What do other
developers think about this?
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Bug#171221: openmotif: openmotif is not a native package
reassign 171221 debian-policy
quit
On Sat, Nov 30, 2002 at 11:42:27PM +0100, Gerd Knorr wrote:
On Sat, Nov 30, 2002 at 05:24:58PM +0100, Gerd Knorr wrote:
should or must? I can't find anything in the policy saying
I *must* package it this way, it just says it is usually done this
way. Thus I hereby close that bug.
It is specified in C.3.
Well, it is exactly that section -- especially the last paragraph --
which IMHO allowes to package the whole thing as one single tarball
instead of .orig.tar.gz + diff. Native debian packages are listed as
typical example for that, but I don't see noted that other packages are
not allowed to be packaged that way.
I'm reassigning this to debian-policy so we can get a general opinion
on this section.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#39830: [AMENDMENT]: get rid of undocumented(7) symlinks
Manoj Srivastava [EMAIL PROTECTED] wrote:
I personally find the undocumented (7) man page frustrating,
since I expected to see documentation, and was told there was none
after a wait (yes, I had a slow machine). I would have much rather
not had my hopes raised, and that man itself told me there was no
manual page.
How about if we made this configurable:
Move undocumented.7.gz to undocumented.real.7.gz
Create a symlink from the former to the latter in the postinst upon
installation or upgrading from a version without it. Then people
who don't want to see it can simply delete the symlink.
They would get a warning from man of course, but that should be easy
to special case in man(1).
Personally I think the manual page would be useful to users new
to Debian.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#120585: apparently what lintian does is valid, ldconfig use outside $1=configure is not documented as safe
Josip Rodin [EMAIL PROTECTED] wrote:
So... please either provide a rationale for this optional invocation, in
which case the lintian warning postinst-unsafe-ldconfig stays just a
warning, or remove the clause, in which case the lintian warning gets
It is perfectly safe to invoke ldconfig unconditionally in a postinst
script. Thus it is OK for a package to simply put ldconfig in its
postinst without checking $1.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#161455: debian-policy: reference to ash outdated
Clint Adams [EMAIL PROTECTED] wrote:
Package: debian-policy
Version: 3.5.7.0
Severity: normal
In 11.4:
You may wish to restrict your script to POSIX features when possible
so that it may use `/bin/sh' as its interpreter. If your script works
with `ash', it's probably POSIX compliant, but if you are in doubt,
use `/bin/bash'.
Debian's ash seems to be renamed to dash now. I suggest changing the
clause to with `posh' or `dash', since posh is less forgiving of POSIX
incompatibilities.
It seems that posh has removed all XSI extensions. The current policy
document does not explicitly state that. I do not think that there is
a concensus about whether XSI extensions should be disallowed.
So I object against including posh until this is clarified.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RFC] *-rc.d - rc.d-* transition
Andreas Schuldei [EMAIL PROTECTED] wrote:
I think it is the right thing to do, since it removes the .d from
the end of the file, which indicates a directory, normally. So we
would avoid missconceptions.
If that's the only reason then this is totally pointless.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: RFD: Essential packages, /, and /usr
Adam Heath [EMAIL PROTECTED] wrote:
There are minor non-posix issues. The biggest is the use of echo -n(don't say
use printf, it's too slow for shoop's target audience).
In the current Debian ash package, echo calls the printf builtin
internally, and I'm yet to see a slow down.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Anthony Towns aj@azure.humbug.org.au wrote:
If it's not to enable backwards and cross-Unix compatability, why do we
care about POSIX at all?
bash, /bin/echo and POSIXLY_CORRECT /bin/echo all treat \c as a literal,
for reference.
GNU has always adopted the BSD behaviour of not interpreting back
slashes. All SYSV shells behaved like
printf %b\n $*
This includes pdksh.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Fri, Jun 21, 2002 at 12:05:38AM -0400, Clint Adams wrote:
9989 * An alias shall be written as a
command line that represents its alias definition.
cf. alias:
| The following operands shall be supported:
|
| alias-name
| Write the alias definition to standard output.
[...]
ls=foo
is an alias definition.
alias ls=foo
is a command line that represents the alias definition.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Wed, Jun 19, 2002 at 02:34:30AM -0400, Clint Adams wrote:
The exact output of command -v is not given by POSIX.
I believe it says
When the -v option is specified, standard output shall be formatted as:
%s\n, pathname or command
Are you referring to the extra new line that ash outputs after an alias?
If so that is indeed incorrect and will be fixed.
More details please.
%s=%s\n, name, value
Will fix.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Thu, Jun 20, 2002 at 08:24:21AM -0400, Clint Adams wrote:
Are you referring to the extra new line that ash outputs after an alias?
If so that is indeed incorrect and will be fixed.
I also interpret the leading literal alias to be incorrect. It's
less useful, at any rate.
In the case of command -v, the alias prefix is required.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Thu, Jun 20, 2002 at 11:32:34PM -0400, Clint Adams wrote:
In the case of command -v, the alias prefix is required.
Reference?
9989 * An alias shall be written as a
command line that represents its alias definition.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Tue, Jun 18, 2002 at 03:56:12AM -0400, Clint Adams wrote:
I'd be happy with SUSv3, UP relevant to non-interactive use, and the
appropriate subset of XSI. Of course, you realize that this reverses
the 'echo -n' exception and that people will cry.
I have nothing against keeping the echo -n clause.
The other problem, then, is that we will have a situation wherein no shell
in Debian would be suitable as /bin/sh (unless I'm assuming incorrectly
about pdksh).
Please be more specific.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Clint Adams [EMAIL PROTECTED] wrote:
Apparently due to sleep-deprivation, I confused Herbert's assertion with
fact. It's set -h that's forbidden. Debian does not need XSI for set -e.
I appologise for this incorrect assertion. I had misread the canonical
form of set. set -e is indeed specified by POSIX.
However, I still maintain that XSI extensions should be specified when it
comes to Debian's /bin/sh:
1. All the existing shells are already compliant AFAIK.
2. There are some features which are regularly used in maintainer
and other scripts which depend on them, e.g.,
the options -a and -o, as well as parentheses for the
test command or [.
the obsolescent forms of kill and trap: kill -INT or kill -9.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Wed, Jun 19, 2002 at 02:00:36AM -0400, Clint Adams wrote:
Please be more specific.
ash:
does not handle multiple heredocs
Thanks, this will be fixed.
read-write fd's do not behave usefully[1]
Not specified by POSIX.
treats $10 as ${1}0
Forbidden by POSIX:
1358 interpreted as a decimal value, even if there is a leading ze
ro. When a positional parameter with
1359 more than one digit is specified, the application shall enclo
se the digits in braces (see Section
1360 2.6.2 (on page 2239)).
does not support cd -L
does not support cd -P
It's on my todo list.
echo -n
Required by the current Debian Policy. Trivial to change should we
ever head in that direction.
incorrect output for command -v
The exact output of command -v is not given by POSIX.
incorrect output for alias
More details please.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Wed, Jun 19, 2002 at 02:26:35AM -0400, Clint Adams wrote:
I've already filed some bugs on 'trap'-misusing packages.
test -a, -o, and parentheses could easily be replaced by and-or listse
Sure, so could command -v. The problem is with the amount of scripts
that use them.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Tue, Jun 18, 2002 at 01:00:25AM -0400, Clint Adams wrote:
I do not see why we should use which. As I have stated previously, we
already require feature sets (set -e in particular) in the new POSIX
document which imply the existence of type(1). So type should be
Can we codify this better?
Certainly,
SUSv3
+
XSI (needed for set -e and other features)
The latter specifies type.
I would also support the addition of UP since all the POSIX shells in
Debian support it with the exception of ash which does not currently
support history. Since history support is unlikely to affect scripting,
it would be acceptable for us to specify UP as well as XSI.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Branden Robinson [EMAIL PROTECTED] wrote:
I hate to break it to you but all the shells that could potentially
serve as /bin/sh in Debian provide type and test as builtins. That
includes ash.
And which(1)?
I do not see why we should use which. As I have stated previously, we
already require feature sets (set -e in particular) in the new POSIX
document which imply the existence of type(1). So type should be
the preferred utility for this task. Besides, as an external utility,
which(1) does not know about shell builtins, which is actually bad.
Consider the hypothetical test:
if type foo; then
foo ...
fi
Assuming that foo is implemented as a builtin in some shells other than
bash, then which(1) would fail to replace type(1) in this case since it
would only succeed had the external version of foo been installed.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Branden Robinson [EMAIL PROTECTED] wrote:
Further, /bin/bash is available and provides both type and test as
builtins.
Bad news for any Debian port that wants to use ash as its Essential
shell, then.
I hate to break it to you but all the shells that could potentially
serve as /bin/sh in Debian provide type and test as builtins. That
includes ash.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#114920: PROPOSAL] remove foolish consistency in perl module names
Joey Hess [EMAIL PROTECTED] wrote:
Herbert Xu wrote:
I object. Until versioned provides work reliably, doing this prevents
any use of versioned dependencies on such packages which may come back
to haunt us.
If something needs to declare a versioned dependency, it need only use
the package's real name in the dependency. There really arn't that many
You're right. Consider the objection withdrawn.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#114920: PROPOSAL] remove foolish consistency in perl module names
Joey Hess [EMAIL PROTECTED] wrote:
Proposal:
Replace section 3.2 of the perl sub-policy included with Debian policy
with the following text:
Packages which contain perl modules should provide virtual packages
that correspond to the primary module or modules in the package. The
naming convention is that for module 'Foo::Bar', the package should
provide 'libfoo-bar-perl'. This may be used as the package's name if
the result is not too long and cumbersome. Or the package's name may
be an abbreviated version, and the longer name put in the Provides
field.
I object. Until versioned provides work reliably, doing this prevents
any use of versioned dependencies on such packages which may come back
to haunt us.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#111025: debian-policy: typo in chapter 9: ldconfig and pre/post scripts
On Sat, Sep 08, 2001 at 06:55:56PM -0400, Steve M. Robbins wrote:
--- policy.sgml.orig Sat Sep 8 16:12:53 2001
+++ policy.sgml Sat Sep 8 17:06:01 2001
@@ -3711,21 +3711,16 @@
/list
/p
/footnote
- must call prgnldconfig/prgn in its prgnpostinst/prgn
- script if the first argument is ttconfigure/tt and should
- call it in the prgnpostrm/prgn script if the first
- argument is ttremove/tt.
- /p
-
- p
- However, prgnpostrm/prgn and prgnpreinst/prgn scripts
- emmust not/em call prgnldconfig/prgn in the case where
- the package is being upgraded (see ref id=unpackphase for
- details), as prgnldconfig/prgn will see the temporary
- names that prgndpkg/prgn uses for the files while it is
- installing them and will make the shared library links point
- to them, just before prgndpkg/prgn continues the
- installation and renames the temporary files!
+ must use prgnldconfig/prgn to update the shared library
+ system. The package must call prgnldconfig/prgn in the
+ prgnpostinst/prgn script if the first argument is
+ ttconfigure/tt; the prgnpostinst/prgn script may
+ optionally invoke prgnldconfig/prgn at other times. The
+ package should call prgnldconfig/prgn in the
+ prgnpostrm/prgn script if the first argument is
+ ttremove/tt. The maintainer scripts must not invoke
+ prgnldconfig/prgn under any circumstances other than those
+ described in this paragraph.
/p
sect
Seconded.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#111025: debian-policy: typo in chapter 9: ldconfig and pre/post scripts
Steve Greenland [EMAIL PROTECTED] wrote:
On 05-Sep-01, 16:52 (CDT), Herbert Xu [EMAIL PROTECTED] wrote:
Vociferous Mole [EMAIL PROTECTED] wrote:
So? Isn't it a bug? This isn't a case of a policy change creating a bug,
but of a existing bug being highlighted by the policy clarification.
It doesn't break anything, so it's not a bug.
I thought we just established that calling ldconfig during 'postinst
upgrade' is wrong. Therefore, all packages simply doing a ldconfig
Where did we establish that? Please point me to the msgid.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#111025: debian-policy: typo in chapter 9: ldconfig and pre/post scripts
Branden Robinson [EMAIL PROTECTED] wrote:
On Tue, Sep 04, 2001 at 08:53:20PM -0400, Steve M. Robbins wrote:
Perhaps the intention of the section 9 paragraph (above) was to
say
However, the postrm script must not call ldconfig if invoked
with the argument upgrade, failed-upgrade, or disappear.
The preinst script must not call ldconfig if invoked with
the argument abort-upgrade.
However, that is a bit longwinded and fairly confusing.
It seems neither to me. The fact that a lot of maintainers are likely
Agreed. If someone can turn that into a diff, I will second it.
BTW, what is it with all the Steves in this thread? :)
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#111025: debian-policy: typo in chapter 9: ldconfig and pre/post scripts
Steve Greenland [EMAIL PROTECTED] wrote:
On 06-Sep-01, 06:59 (CDT), Herbert Xu [EMAIL PROTECTED] wrote:
BTW, what is it with all the Steves in this thread? :)
Is your problem that there are so many of us, or that we seem to be
excessively dim? I personally blame insufficient caffiene...
Three Steves in one thread... Anyway, I now know that it's only two Steves :)
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#111025: debian-policy: typo in chapter 9: ldconfig and pre/post scripts
On Tue, Sep 04, 2001 at 08:53:20PM -0400, Steve M. Robbins wrote:
On Mon, Sep 03, 2001 at 06:52:55PM +1000, Herbert Xu wrote:
Would there be a problem with enshrining this with the following
policy simplification?
Nope. It still has the same problem, i.e., all packages simply doing a
ldconfig in their postinst is now violating the policy.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#111025: debian-policy: typo in chapter 9: ldconfig and pre/post scripts
Vociferous Mole [EMAIL PROTECTED] wrote:
So? Isn't it a bug? This isn't a case of a policy change creating a bug,
but of a existing bug being highlighted by the policy clarification.
It doesn't break anything, so it's not a bug.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#111025: debian-policy: typo in chapter 9: ldconfig and pre/post scripts
Steve M. Robbins [EMAIL PROTECTED] wrote:
--- policy.sgml.origSun Sep 2 22:50:21 2001
+++ policy.sgml Sun Sep 2 22:52:26 2001
@@ -3718,7 +3718,7 @@
/p
p
- However, prgnpostrm/prgn and prgnpreinst/prgn scripts
+ However, prgnpostrm/prgn and prgnpostinst/prgn scripts
emmust not/em call prgnldconfig/prgn in the case where
the package is being upgraded (see ref id=unpackphase for
details), as prgnldconfig/prgn will see the temporary
Objection. There's nothing wrong with calling ldconfig in the postinst
durinag an upgrade. This change instantly creats a bucket load of RC
bugs for no good reason.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#106280: packages shouldn't have to ask permission before calling MAKEDEV in postinst
Anthony Towns aj@azure.humbug.org.au wrote:
...or an echo. Seconded.
Better make that a printf :)
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#36151: Clearing out old policy proposals
On Mon, Jun 25, 2001 at 09:26:20AM +0100, Julian Gilbey wrote:
misconfigured, then that solves his problem. Does the general
suggestion retain much value, though?
Personally I don't see why a root user should have a PATH that does not
contain sbin and /usr/sbin.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#36151: Clearing out old policy proposals
Julian Gilbey [EMAIL PROTECTED] wrote:
On Fri, Jun 22, 2001 at 09:08:10AM -0500, Steve Greenland wrote:
I'd really like to see the list expanded to include /sbin and /usr/sbin
as well. My rationale is that init.d scripts are intended (and mostly
Please see the original proposal: the problem was precisely that there
were situations where these directories were not in the PATH and this
broke the scripts.
Only because the user's system was misconfigured...
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#36151: Clearing out old policy proposals
Steve Greenland [EMAIL PROTECTED] wrote:
I'd really like to see the list expanded to include /sbin and /usr/sbin
as well. My rationale is that init.d scripts are intended (and mostly
only useful) for the root user, and the the whole point of /sbin
and /usr/sbin is to contain scripts useful for the root user. It is
completely reasonable to assume that those directories are in the path,
and my opinion is that if they aren't, the admin needs to fix their
system.
Exactly. In fact, if we did anything to promote the automatic adding of
/sbin and /usr/sbin to the PATH variable, then the default behaviour of
dpkg where it fails if things like start-stop-daemon isn't found in a
PATH search would stand out like sore thumb.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#36151: Clearing out old policy proposals
Steve Greenland [EMAIL PROTECTED] wrote:
Bug #36151: etc/init.d scripts should specify an explicit PATH
Summary: init.d scripts shouldn't depend on having PATH set in a
useful manner -- they should explicitly set the PATH. Not much
discussion in the bug logs, and most of the flame^H^H^H^H^Hdiscussion
took place on debian-devel. Result inconclusive. Last few notes
in BTS are that it should be part of the coding guidelines, not
policy
Discussion: No additional comments
Action: Retitle as GUIDELINE for future reminder.
This proposal is backwards. Not only should we not set PATH in /etc/init.d
scripts, we should disallow packages from doing so (except for including
extra directories). The reason is that it does away with the whole point of
the PATH variable, which is to allow the caller to override binaries.
For example, if the script didn't set PATH, I could put /usr/local/sbin in
front of it to override start-stop-daemon. This simply isn't possible if
PATH was set.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#100346: PROPOSAL] Do not mandate existence of shared libraries
Richard Braakman [EMAIL PROTECTED] wrote:
The full description of it is in the logs of bug#35049.
It's a bug in libc6-dev which has since been fixed. If you look at the
file libc_nonshared.a in slink, you'll find that the offending symbols
didn't have the .hidden flag while they do now.
To get back to the policy proposal, I do think there are libraries
that should not have shared versions. Namely, ones that are not
yet at a point of their development where it makes sense to have
a stable binary interface. If Debian were to release a shared
version, that would mean picking a soname (and thus forcing upstream
to live with that soname, which can be annoying if they had a different
numbering scheme in mind), and it would mean changing the soname
for every upstream release. For some libraries that's just not
worth it.
I would agree in principle. However, if a library was in such a state
for an extended period of time, then I would start to question its status.
I also present publib-dev as an example of a library which currently
provides only a static version, but I will let its maintainer speak
for himself :-)
I won't bitch as long as there is nothing on my system that uses it, or
at least as long as I don't know about it :)
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#100472: PROPOSAL] allowing '-' between libraryname and soversion
Andreas Bombe [EMAIL PROTECTED] wrote:
Package: debian-policy
Version: 3.5.5.0
Severity: wishlist
$ egrep '^Package: lib.*-[[:digit:]]*$' unstable-Packages
Package: lib3ds-1.0-0
Package: libasis-3.13p-1
Package: libgnat-3.13p-1
Package: libgtrans-mysql-3-23
Package: libgtrans-postgresql-6-5-3
Package: libid3-3.7-13
Package: libmath3d-0.3-0
Package: libnewt-utf8-0
Package: libole2-0
Package: libraw1394-5
The last three are what I am talking about specifically (libraw1394 is
mine, btw), generally this also applies to the version-in-name problems
seen above (don't ask me wtf libgtrans is up to).
Although the kernels aren't shared libraries, they are in the same boat
and hyphens have been used there since very early on, e.g., we have
kernel-source-2.4.5.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#100346: PROPOSAL] Do not mandate existence of shared libraries
Richard Braakman [EMAIL PROTECTED] wrote:
On Mon, Jun 11, 2001 at 09:20:48AM +1000, Herbert Xu wrote:
Florian Weimer [EMAIL PROTECTED] wrote:
and neither is libc6 because some parts of it can only be linked
statically.
Which ones?
/usr/lib/libc_nonshared.a. It contains atexit() and a lot of
stat() functions. This has caused breakage in bash and libreadline
in the past; I can look up the bug number if you're interested.
Each one of these has a valid reason to exist. They are necessary evils
when you need to provide backward ABI compatibility. They are all in fact
simple wrappers around real functions which are shared. Intuitively, these
are not what the policy is trying to target. Perhaps the exception should
be noted, somewhere.
As to the bash breakage, please quote the number. Thanks.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#100346: PROPOSAL] Do not mandate existence of shared libraries
Florian Weimer [EMAIL PROTECTED] wrote:
This means that the current GCC 2.95.x package is not conforming to
the policy because it doesn't provide a shared version of libgcc.a,
It's fixed in GCC 3.0.
and neither is libc6 because some parts of it can only be linked
statically.
Which ones?
If the libraries that you're referring to aren't .a's then this section
doesn't even apply.
Of course ,these languages use the standard object file formats. They
simply do not support shared libraries well (think of the fragile base
class problem, or the effect of certain forms of name mangeling).
Well, perhaps your time would be better spent in addressing these issues.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#100346: PROPOSAL] Do not mandate existence of shared libraries
On Mon, Jun 11, 2001 at 01:35:30AM +0200, Wichert Akkerman wrote:
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.
You mean:
$ ls /lib/libnss*
/lib/libnss_compat-2.2.3.so
/lib/libnss_compat.so.2
/lib/libnss_db-2.2.so
/lib/libnss_db.so.2
/lib/libnss_dns-2.2.3.so
/lib/libnss_dns.so.2
/lib/libnss_files-2.2.3.so
/lib/libnss_files.so.2
/lib/libnss_hesiod-2.2.3.so
/lib/libnss_hesiod.so.2
/lib/libnss_nis-2.2.3.so
/lib/libnss_nis.so.2
/lib/libnss_nisplus-2.2.3.so
/lib/libnss_nisplus.so.2
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#100346: PROPOSAL] Do not mandate existence of shared libraries
Florian Weimer [EMAIL PROTECTED] wrote:
Package: debian-policy
Version: 3.5.4.0
Severity: wishlist
In section 11.2, it is mandated that every library provides a static
and a shared version. I don't think this is appropriate, as there
are programming languages whose shared library support is still
evolving.
The whole discussion in this section seems to be quite C-centric.
I would object against any weakening of the policy which allows packages
to provide .a's without corresponding packages with .so's.
If the libraries that you're referring to aren't .a's then this section
doesn't even apply.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Bug#99324: Default charset should be UTF-8
Radovan Garabik [EMAIL PROTECTED] wrote:
Arabic and hebrew have problem of being written right-to-left,
and therefore they cannot be easily supported, unicode or not.
That's a display issue, not an encoding one.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: mandate ldconfig -X?
Robert Bihlmeyer [EMAIL PROTECTED] wrote:
Background:
ldconfig has two purposes:
1. For each shared library, create/update a symbolic link from the
library's soname to the library file. The link is only changed if
it was broken/non-existing before, or the library in question has a
higher version than the current destination of the link.
2. Update the locations of shared libraries in /etc/ld.so.cache
Per default, ldconfig will execute both actions.
...
The second action is generally useful. ldconfig -X will do just
that, and omit the first.
Why should we not commit the first action anyway?
If ldconfig was written properly, then the first action should be pretty
much a noop if the symlinks are present. After all, you still have to
stat everything to find out what the symlink should point to, and the
first action merely adds an stat if the symlink exists.
If this is not how ldconfig works currently, then it should be fixed.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Tightening up specification of /bin/sh
Zack Weinberg [EMAIL PROTECTED] wrote:
I'd like to tighten this up a bit by requiring that /bin/sh adhere to
the consensus of implementations, where POSIX leaves things
unspecified. What follows is one possible revision. The wording
isn't ideal; I'm open to suggestions.
I object most strongly. The only reason why things like POSIX exists is
because in general there is no consensus.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Defaults for satisfying dependencies - ordering gone?
On Sun, May 13, 2001 at 01:54:08PM +0200, Josip Rodin wrote:
That is, ae, which is required. In another place, Policy says:
`required' packages are necessary for the proper functioning of
the system. You must not remove these packages or your system
may become totally broken and you may not even be able to use
`dpkg' to put things back.
However, the policy also says:
Every package must specify the dependency information about other
packages that are required for the first to work correctly.
For example, a dependency entry must be provided for any shared
libraries required by a dynamically-linked executable binary in a
package.
Packages are not required to declare any dependencies they have on
other packages which are marked `Essential' (see below), and should
not do so unless they depend on a particular version of that package.
I agree that in this particular case, the distinction is only of academic
interest. Nevertheless, it may come back to bite us later should we wish
to rely on the fact that only essential packages have implicit dependencies
on them.
Intuitively, non-essential required packages should only exist if they're
depended on by essential ones. That's why I have a problem with ae being
a non-essential required package when nothing essential depends on it.
If they knew how to screw up their system by removing all of the editors,
they'll know how to fix it by adding back some editors. This isn't
fool-proof, but so what?
Agreed.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Defaults for satisfying dependencies - ordering gone?
On Sun, May 13, 2001 at 12:38:05PM -0700, Thomas Bushnell, BSG wrote:
* Create a real package editor-proxy, which depends on editor, and
is marked Essential.
You don't even have to do that. Just make base-files depend on it. It
already depends on awk anyway.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Defaults for satisfying dependencies - ordering gone?
Josip Rodin [EMAIL PROTECTED] wrote:
On Sun, May 13, 2001 at 12:38:05PM -0700, Thomas Bushnell, BSG wrote:
Why is that not viable?
Do the following:
* Make all the different editor packages provide the virtual package
editor.
* Create a real package editor-proxy, which depends on editor, and
is marked Essential.
And then have a couple of hundred packages that use invoke editor depend on
it, and after that have a couple of thousand packages depend on it because
they depend on it implicitely...
Nope. It will truly be essential without actually being marked essnetial
as an essential package depends on it. So this actually avoids the need
for explicit dependencies.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Defaults for satisfying dependencies - ordering gone?
Josip Rodin [EMAIL PROTECTED] wrote:
It's useless to have a virtual package that thousands of packages would have
to have a dependency on, it's too much work for too little gain. Cf.
essential packages.
The comparison breaks down as there isn't an editor which is actually
essential.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Defaults for satisfying dependencies - ordering gone?
Josip Rodin [EMAIL PROTECTED] wrote:
On Sat, May 12, 2001 at 11:04:14PM +1000, Herbert Xu wrote:
The comparison breaks down as there isn't an editor which is actually
essential.
Yes, but _an_ editor is almost essential. Well, it's essential all right if
you consider that things like dircolors or nl are essential, but some people
will never use them (like there are people that will never use editors).
From a package dependency point of view, almost essential is a world away
from actually being essential. It's the difference between being able
to rely on its existence without depending on it and the need to declare
an explicit dependency whenever you use it.
IMHO we just need to declare the said editor (or whatever else we agree on)
essential and be done with it.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Defaults for satisfying dependencies - ordering gone?
Josip Rodin [EMAIL PROTECTED] wrote:
On Sun, May 13, 2001 at 09:07:30AM +1000, Herbert Xu wrote:
From a package dependency point of view, almost essential is a world away
from actually being essential.
Packages can assume that the user has means of editing config files without
declaring a dependency on any single editor.
If you feel it's not comparable to the situation where packages can assume
they can run ls without declaring a dependency on fileutils, fine, but
that's nitpicking...
I'm not talking about editing config files here. I'm more interested in
programs that invoke /usr/bin/editor.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Defaults for satisfying dependencies - ordering gone?
Josip Rodin [EMAIL PROTECTED] wrote:
On Sun, May 13, 2001 at 10:38:09AM +1000, Herbert Xu wrote:
I'm not talking about editing config files here. I'm more interested in
programs that invoke /usr/bin/editor.
Well, see Policy section 12.4. Editors and pagers.
Your point being? As it is, you're allowing all editors to be removed
without dpkg bitching about it and suddenly all these programs calling
editor will start failing.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Bug#94827: tktable; Build-Depends: debhelper
Steve Greenland [EMAIL PROTECTED] wrote:
No, I'm suggesting that build-depends could simply have an unversioned
depends on debhelper. The buildds would then always[1] have the latest
version of debhelper[2]. No effort required of the build-depends maint.
But build-time dependencies aren't just for buildd's. Humans need them too.
I wouldn't like to have to compile a package and fail near the very end just
because it hasn't declared a proper versioned build-depends on debhelper.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Policy for stripping binaries
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
runs
lintian with -I, I have had several bugs linger for a while that only come
out
when -I is active and no one ever saw them.
What kinds of bugs? The criterion I used for info-level tags was that
they were not bugs, just things a maintainer might want to know about
the package.
I think he's referring to bugs in lintian.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Bug#94114: mesag3-glide2: mesag3-glide2 needs MESA_GLX_FX
On Mon, Apr 16, 2001 at 04:16:34PM +0200, Marcelo E. Magallon wrote:
I never said that's not possible. I'm just saying this is not the way
*this* library works. Since I don't use this particular feature of
Mesa, I don't know why this is so. If you read README.3DFX you'll note
this is the least interesting environment variable there is. It has
three possible values, and none is a good default, because, AFAICS,
it's hardware and configuration dependent.
But it has chosen a default anyway. I mean it didn't just bomb out, it
actually kept working while producing a warning message telling the user
to set the environment variable. What the policy is saying is that the
environment variable shouldn't be the only way of choosing this setting,
it must be possible to set this via a configuration file as well.
If a program usually depends on environment variables for its
configuration, the program should be changed to fall back to a
reasonable default configuration if these environment variables
are not present.
My point is there is no reasonable default. The choices are
fullscreen (which might not make sense if you have only one monitor),
windowed (which is slow) and disabled (which, err... isn't the reason
why you bought the card in the first place).
But the library choose a default anyway.
Policy is oriented towards programs, it even suggests the use of a
wrapper for those circumstances where it's difficult to change the
program.
The wrapper only comes into play if the program (which I argue applies
to libraries as well as executables) is difficult to modify. Which I
don't think is the case here.
Anyways, I can fix this, but don't expect it to happen soon. This is
not the only variable that's used by Mesa.
Well, then it would be a good thing if it had a configuration file.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Policy rewrite: chaps 11-13
Chris Lawrence [EMAIL PROTECTED] wrote:
read the paragraph, at least. Having said that, I suspect that it's
more robust to do the adduser in the postinst than in the preinst,
Since adduser is not essential, it has to go into postinst unless there is
a predependency.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#90511: proposal] disallow multi-distribution uploads
Ben Collins [EMAIL PROTECTED] wrote:
Running a buildd, I have the problem of builds that come in for stable
and unstable. Currently this means the buildd performs the compile on
stable, and either uploads to stable unstable, or as it were
Is there a reason why this option won't work?
It's my opinion that same version uploads to stable/unstable are harful
to archive and distribution integrity. I've talked this over with James
Troup, and he seems to agree with the points below, and is considering
enforcing them via dinstall checks. My intention is to get the weight
of policy behind this.
I disagree. Allowing uploads to both stable and unstable reduces maintainer
load, so that they can spend their precious time doing useful work rather
than needlessly recompiling things.
Technical reasoning:
1) Building for stable unstable means that 99% of the time the build
is performed on a box running stable. So the package will be compiled
against stable libraries. Now we all know that most of the major
libraries will go on to new major versions between releases. Ncurses (4
to 5 between slink and potato), readline (2 to 4 between slink and
potato), gnome (several revisions during potato development, and others
now), libstdc++ (which changes with the libc6 major upgrades), etc...
Now, a lot of libraries keep an oldlib around for backward compatibility
of packages that have not been recompiled for the newest version of the
lib. This is a less than optimal situation since it must be maintained
just like any other package. If libncurses4 is in stable, and
libncurses5 is in unstable (with the 4 version around only for backward
compat), then builds in unstable should be using the libncurses5.
However, someone compiling for stable unstable uneedingly prolongs
this oldlib's life.
But you need to keep old libraries around anyway for compatibility with
other Linux distributions. We're not the only Linux distribution here.
In fact, having some unstable packages compiled on stable is a
Good Thing (TM). It means that we actually test whether our libraries
are lying when they claim to have kept their ABI intact (glibc would be
a prime example). You won't be able to do this if everybody compiled their
unstable packages against unstable.
Of course, if a package doesn't compile on unstable, that would be a
different matter, and a severity serious bug.
2) Policy changes. This is probably the worst case. We all know that
policy abiding build-helpers change between releases just like policy
does. Take the usr/doc-usr/share/doc changeover scripts, and the X
default scripts used and hardcoded during the build. Building on stable
and unstable produces 2 different packages, abiding by two different
policies.
This is a separate issue. If there's no way to build a package such that
it complies with both sets of policies, then it shouldn't be built for both
distributions. Indeed, you can already file serious bugs against such
packages armed with our current policy.
3) Build failures. It is commonly the case that a package built on
stable will not compile on unstable, even though it works runtime wise.
That is a problem, but I don't think it is serious enough to warrant the
prohibition of multi-distribution uploads.
Issues:
The only issue I forsee is the likely even of where an upload to stable
and unstable is desired. I suggest that policy specify this to be done:
If package blah is in stable/unstable of version 1.0-1 (meaning it has
not changed since stable was released) and an upload must be done for
both stable and unstable of 1.0-2, then the stable upload must be
1.0-1.90 and unstable must be 1.0-2. This is similar to an NMU. The
reason for the .90 is similar in spirit to how glibc starts a
pre-release series (IOW, pre-releases for 2.2 start at 2.1.90).
If the package in question cannot be uploaded to both stable and unstable
for reasons such as policy disparity, library compatibility, then yes this
is what should be done. But that's what we've been doing anyway. Except
of course that the version number is 1.0-1potato.1 (replace potato with the
name of the current stable distribution). Otherwise, IMHO this just wastes
the time of the maintainers involved.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#90511: proposal] disallow multi-distribution uploads
On Wed, Mar 21, 2001 at 10:37:56AM -0500, Ben Collins wrote:
Remember that the majority of uploads to stable are done by the security
team and the buildd's. I don't think this is a lot of effort for the
maintainers, since it isn't done often enough to be cumbersome, like it
would have been for frozen unstable uploads.
Well this hasn't been the case in my experience. Most of the security
problems that has occured in my packages resulted in uploads by myself, not
the security team.
Think of a base system. If things are allowed to continue this way, it
means the base system will be comprised of a lot of different versions
of the same library. That makes a base install larger
This is a different issue. Besides, you won't solve it by gettint people
to do different uploads since they can compile both on stable (some
developers only run stable machines immediately after a release). What you
need to here is to file bug reports against packages that compile against
obsolete sonames.
This isn't about keeping old libraries around. For one, people can
always get it from the old dist, or they will just keep it installed and
not remove it. This is about the libraries required by Debian packages
themselves. New uploads should always strive to be built agains the
latest packages, to reduce the dependency chain in the dist, and
increase integrity of the compile base.
But you won't solve the soname problem by doing this since uploading to
unstable doesn't mean that the package was actually compiled on unstable.
Personally bug reports have been just fine in solving this problem.
And as I said in my previous message, for libraries with the soname
(like glibc), you do want to test it against old -dev packages to ensure
binary compatibility.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)
Ben Collins [EMAIL PROTECTED] wrote:
As for the first. Multi distributions occur so infrequently that it
should not be a problem to do this. Most of the time a package is
already diverged between stable and unstable, so two uploads are still
required in that case for security fixes. Enforcing this just means we
have more consistency. Allowing it for convenience makes no technical
sense.
Perhaps this has been your experience (understably since you maintain a lot
of library packages that are actively developed). However, im my
experience, I've certainly done my fair share of stable unstabe uploads,
and I do not welcome the prospect of having to double those just to solve
some non-existant problem.
As for allowing them in cases where they don't fall into any of my
listed points of breakage, I ask that you give a solid technical reason
why even those should be allowed, other than simple convienience. I see
no reason for it. In fact, the only technical reason was back when we
had frozen/unstable uploads, and they do not occur any longer.
As I said, it is a good thing to have packages compiled against old libc-dev
packages since that actually tests whether libc6 has been true its words
when it says that its ABI is still the same. In any case, IMHO the more
interesting question is why they shouldn't be allowed in this case?
However, my main objection to this proposal is that it solves none of your
problems as disallowing simultaneous uploads does not equate to disallowing
the building of unstable packages on stable.
So in fact you're proposing the wrong solution to your problems. Which has
the unfortunate side effect that some maintainers will be wasting time
doing double compiles that they know will come out to be the same.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)
On Wed, Mar 21, 2001 at 04:10:20PM -0500, Ben Collins wrote:
Yes it does help. By allowing stable/unstable uploads, we implicitly
allow maintainers to do something potentially harmful and with almost
zero technical gain. By disallowing it, we raise awareness that it is
most commonly not a good idea.
IMHO you can't solve social problems with technial solutions.
Testing libc6 backward compatibility is not the purpose of
stable/unstable uploads. That is something that needs to be tested
But it is a side effect for packages depending on libc6.
elsewhere. Allowing stable/unstable uploads does not guarantee any of
this, and is a bad way to test it. For example, many packages should be
using new interfaces in libc6 for LFS, and not using the db libraries
that were obsoleted. Compiling against potato increases the lack of LFS
support in our unstable distribution, and increases the use of obsoleted
parts of libc6. Neither of these things are technically meritable.
As I have said many times already, this is a *different* problem.
If a package can benefit from LFS and it hasn't been built with LFS, file a
bug report. If a package uses obsolete db packages, file a bug report.
Disallowing stable unstable uploads will *not* solve this problem.
So if you want to test libc6, then get a potato and a sid machine (or
setup a chroot), and compile your package for potato, and run it in the
sid system. Don't go uploading a potato compiled package to sid just to
test libc6's binary compatibility.
But why not? If there's no other reason (all the ones you've listed can
already be solved by bug reports against the relevant packages and won't
be solved by doing this anyway), compiling it on stable is just as good as
compiling it on unstable. In fact, I still contend that it is better
because you are aactually testing whether the libraries involved are
compatible or not.
So in fact you're proposing the wrong solution to your problems. Which has
the unfortunate side effect that some maintainers will be wasting time
doing double compiles that they know will come out to be the same.
No, I'm proposing a large portion of the fix. The other portion may be
needed, if the problems persist. No amount of policy can stop this
completely, even if we forbid (and enforce via dinstall) not using
oldlibs as deps, since that doesn't enforce policy things like doc
directories and X application defaults, and buildability on unstable.
Well that's where our opinions differ. My perception is that not only
doesn't this solve a large proportion of those problem cases, it also has
the nasty side effect that maintainers of packages where your concerns do
not stand will be wasting time recompiling packages.
You still have not given any technical merit to allowing stable/unstable
uploads other than convenience, which is not on my list of technical
terms.
Obviously you disagree with me about what is a technical merit. IMHO,
testing ABI compatibility of libraries like libc6 is aa technical merit.
In any case, I don't see why we should be discussing what technical merits
there are in these uploads, but what technical merits exist in disallowing
them as I haven't seen any of those which are valid either.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#90511: An alternative solution to old libraries problem
Here's an (IMHO) better way of solving the old libraries problem:
1. If a package depends on anything in section oldlib in a distribution,
it isn't allowed in to that distribution.
2. Disallow uploads to stable unstable that can't go into both of them.
Of course, you need to override this check for nonfree packages since they
may not have source.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)
On Wed, Mar 21, 2001 at 04:35:58PM -0500, Ben Collins wrote:
Testing libc6 backward compatibility is not the purpose of
stable/unstable uploads. That is something that needs to be tested
But it is a side effect for packages depending on libc6.
And side affects are often bad, as they have unforseen problems.
Are you saying that packages compiled against old libc6-dev packages are
not guarranteed to work with a new libc6? Well, better tell that to all
the application vendors out there.
against stable. Yes bug reports can do this. However, when you upload a
package built against stable, the buildd's use unstable, so now you have
feature skew across architectures. That is a bad thing.
Here's the crux of your current problem. The buildd is broken. In your
original message, you actually said that the buildd should build on stable
for such uploads, which would be the correct thing.
Also, we want our latest features to be tested. Compiling against stable
does not do this, so we have less testing on the things that matter for
the next release.
Disallowing stable unstable uploads has a very small effect on this.
In any case, I don't see why we should be discussing what technical merits
there are in these uploads, but what technical merits exist in disallowing
them as I haven't seen any of those which are valid either.
I've already covered those, but you have blown them all off. I don't see
That's exactly my feeling as well, except the other way around.
how you can argue against them. Those problems exist for a majority of
the uploads that would be done for stable/unstable. Just because the
problems don't affect a few possibilities, does not give merit to
allowing such things, it just means they don't have problems. Nothing
good comes from doing a stable/unstable upload.
The problem is that the bad things which come from it are not due to the
fact that they are stable unstable uploads.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)
On Wed, Mar 21, 2001 at 04:51:06PM -0500, Ben Collins wrote:
On Thu, Mar 22, 2001 at 08:42:16AM +1100, Herbert Xu wrote:
Are you saying that packages compiled against old libc6-dev packages are
not guarranteed to work with a new libc6? Well, better tell that to all
the application vendors out there.
No, but other libraries may show this problem. Not just that, but
Any libraries which change the ABI without changing the soname is buggy,
period.
compiling against libc6-dev 2.1.3 does not mean it will compile against
libc6-dev 2.2.2
That's a different problem.
No, you misinterpret this. I am saying that if you build against
stable (see above, that is what I said), then the buildd's will
compile against unstable for an unstable upload. So you argument about
allowing testing of backward compatibility applies here. You are
creating feature skew.
Well for stable unstable uploads, the buildd should build it on stable,
and upload it to stable unstable. IIRC this is what you said in your
first message.
Disallowing stable unstable uploads has a very small effect on this.
That's arguable, and not technically founded. However, allowing
stable/unstable uploads implicitly allows this to happen. So if we
enforce this in the long run, as you suggest, we will have to stop
stable/unstable uploads anyway.
Not for me. Most of my stable unstable uploads are for the kernels
which do not interact with libraries in any way.
Of course they are. It means the packages have to be compiled on stable
and uploaded to unstable. It means there is no way around that, and
problems do occur because of it. By disallowing them, we are a step
Well my point is that disallowing stable unstable doesn't solve those
problems for most packages, as stable unstable uploads are rare to start
with. And for packages which don't have these problems, this incurs
significant overhead on the part of the maintainer.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#89473: PROPOSAL] dpkg-statoverride and Conflicts: suidmanager ( 0.50)
Julian Gilbey [EMAIL PROTECTED] wrote:
Yes, when I started this thread, I hadn't thought of this case. But
I've now become convinced of the need to have a distinction between
maintainer statoverrides, for cases like this, and local
statoverrides, which take precedence.
Not necessarily, this is what I did in telnetd:
if [ -z $(dpkg-statoverride --list /usr/lib/telnetlogin) ]; then
chown root.telnetd /usr/lib/telnetlogin
chmod 4754 /usr/lib/telnetlogin
fi
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#89674: PROPOSAL] Clarify ldconfig usage
Package: debian-policy
Version: 3.5.2.0
Julian Gilbey [EMAIL PROTECTED] wrote:
Package: debian-policy
Version: 3.5.2.0
Severity: wishlist
Proposed patch:
Any package installing shared libraries in a directory that's listed
in `/etc/ld.so.conf' or in one of the default library directories of
`ld.so' (currently, these are `/usr/lib' and `/lib') must call
`ldconfig' in its `postinst' script if and only if the first argument
-is `configure'. However, it is important not to call `ldconfig' in
When did this (postinst can only call ldconfig if $1 = configure) become
policy? Not only is this pointless, it also means that a lot of packages are
now in violation of this policy. I propose that the and only if phrase be
removed from the above sentence.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Policy rewrite: chaps 7-10
Wichert Akkerman [EMAIL PROTECTED] wrote:
It should say what it currently says.
7.2 Depends: should also mention or if it is required by the
postinst, prerm or postrm scripts.
Remove postrm from there, that can't rely on the Depends being present.
Is this just postrm purge or all invocations of postrm? If the latter,
then surely some forms of prerm can't assume dependencies either?
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#89674: PROPOSAL] Clarify ldconfig usage
Julian Gilbey [EMAIL PROTECTED] wrote:
That's probably correct; they function perfectly if everything works,
but if the postinst ends up being called with an abort-* argument, I'm
not sure that it would. Any experts out there?
As postinst is always the last thing that dpkg does on a package, if it
does break, then you'd be in trouble anyway as the next package that comes
along and runs ldconfig will break as well.
Perhaps we can temporarily change must not to should not?
We should simply remove the and only if part.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#88058: PROPOSAL] ftp-client virtual package
On Thu, Mar 01, 2001 at 10:56:12AM +, Julian Gilbey wrote:
These are real issues; I'm forwarding them to the ftp and ftp-ssl
maintainers.
When I made ftp provide ftp-client, I thought ftp-client was already a
virtual package. Since this appears not to be the case, I will remove
that provides in the next release.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#83669: dynamic creation of libx.so.n
On Mon, Feb 05, 2001 at 01:13:44PM +1100, Brian May wrote:
As such, I recommend that we change this bug title to:
dynamic creation of libx.so.n
Sorry, but this has been solved ages ago in ldconfig :)
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#83669: dynamic creation of libx.so.n
On Mon, Feb 05, 2001 at 05:06:29PM +1100, Brian May wrote:
Maybe so, but then Debian packages shouldn't include the symlink in
the runtime library package.
It doesn't need to. Just call ldconfig to make the symlink.
Also, who is responsible for deleting the symlink when it is no longer
required? Does ldconfig do that?
ldconfig doesn't. But it isn't that hard to remove dangling symlinks
in those directories, be it by ldconfig or some other utility.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Directing Debian users to use project BTSes - should we?
Sam TH [EMAIL PROTECTED] wrote:
Well, speaking as an upstream author, downstream bugs, so to speak,
are quite annoying, in that significant effort has to be expended to
track and fix and close them in a dozen different bug tracking
systems. It would be significantly more conventient for upstream
You wouldn't have to do that if your downstream maintainer were doing his
job properly and forwarding the bugs to you.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Directing Debian users to use project BTSes - should we?
On Sun, Feb 04, 2001 at 01:20:56AM -0600, Sam TH wrote:
But the problem is that we have so many downstream maintainers.
AbiWord is distributed by every major distribution, plus it's a part
of GNOME, and of Ximian GNOME. So that's about 10 different BTSs, and
10 sources of bug reports and patches.
Yes, but my point is that if the Debian maintainer were doing his job
properly, then at least you wouldn't have to bother about tracking the
Debian BTS since all the relevant reports should have been forwarded to
you.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Directing Debian users to use project BTSes - should we?
Chris Waters [EMAIL PROTECTED] wrote:
Well, I'm not sure if it's technically allowed or not, but I'm sure
Frank would allow you to forward the reports yourself, since you, at
least, probably know what you're doing. My point remains, however,
It's certainly technically possible since the Debian BTS is a totally
open system.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#83669: Shared libraries
Marcelo E. Magallon [EMAIL PROTECTED] wrote:
Herbert Xu [EMAIL PROTECTED] writes:
and allow shlibs with different minor version numbers to be installed
together by encoding it into the package name. Of course, we'll have
to manage /usr/lib/libfoo.so.2 dynamically as well.
Break the second you run ldconfig. Plus the fact that the dynamic
linker doesn't know about major and minor version numbers, only about
sonames.
Not if you manage it through ldconfig. BTW, ldconfig does know about
version numbers. Read the source.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#83669: Shared libraries
Marcelo E. Magallon [EMAIL PROTECTED] wrote:
I don't think I understand what you mean by manage here. You can't
prevent users from running 'ldconfig'. If you run 'ldconfig' it will
read the sonames and place symlinks to the newer versions of the
library.
If you've got both foo 2.0 and foo 2.1 installed, ldconfig will symlink
foo 2.1 it to foo.so.2 which is exactly what you want.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#83669: Shared libraries
Ian Jackson [EMAIL PROTECTED] wrote:
Currently, wrt shared libraries, we mandate (or do) this:
foo2 (2.1) /usr/lib/libfoo.so.2 - libfoo.so.2.1
/usr/lib/libfoo.so.2.1 (actual library)
foo-dev (2.1) /usr/include/foo.h
/usr/lib/libfoo.so - libfoo.so.2
How about
/usr/lib/libfoo.so - libfoo.so.2.1
and allow shlibs with different minor version numbers to be installed
together by encoding it into the package name. Of course, we'll have
to manage /usr/lib/libfoo.so.2 dynamically as well.
This would require changing how dpkg-shlibdeps works though.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#83669: Shared libraries
On Fri, Jan 26, 2001 at 08:34:07PM -0600, David Engel wrote:
I think this would be more trouble than it's worth. Not only would
That's probably true.
packagers have to deal with all of the possible overlaps between
packages, it would also potentially add even more packages to the
archives.
I thought that Ian's proposal was aimed at allowing such disparities to
exist rather than (necessarily) having them in one distribution. So in the
case of libc6 2.1 and libc6 2.2, potato would have libc6 and libc6-dev
2.1 while woody would have libc6 and libc6-dev 2.2. Having his scheme
would allow you to upgrade your libc6 to the woody version while maintaining
the libc6-dev from potato.
Under the scheme that I described, the same thing can be achieved without
having two versions of the same library existing in either potato or woody.
This would require changing how dpkg-shlibdeps works though.
Perhaps not. Most situations could probably be handled by simply
moving the .shlibs files from the run-time packages to the -dev
packages.
Yes, but this requires changing dpkg-shlibdeps. Besides, it's not exactly
easy to figure out what -L flags were used during the compile and hence find
the correct .so file.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#77400: PROPOSAL] require packages to disable /etc/logrotate.d files on removal
Arthur Korn [EMAIL PROTECTED] wrote:
Package: debian-policy
Addition to section 4.8 Log files:
--
A better scheme is to use logrotate, a GPL'd program developed
by Red Hat, which centralizes log management. It has both a
configuration file (/etc/logrotate.conf) and a directory where
packages can drop logrotation info (/etc/logrotate.d).
+
+In config-file state, the /etc/logrotate.d/pkgname file should
+be suffixed with .disabled (this is required if other
+ packages use the same logfile).
-
Have a look at Bug#77314 for an example of the breakage that not
doing so can cause.
This looks like a rather ugly solution.
Why not add new a directive to the logrotate.d files that checks for the
existence of files so that we can do something similar to the init.d scripts,
or even better, a directive that actually queries the status of a package.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#73620: Policy example about INSTALL is wrong
Yves Arrouye [EMAIL PROTECTED] wrote:
Package: debian-policy
Version: 3.2.1.0
Section 4.1 of the policy manual says to build after setting
INSTALL = install
In addition to the fact that the example should use INSTALL_PROGRAM because
of the strip example later in this section, the value of the variable should
be /usr/bin/install. If it is set to a non-absolute path, configure will add
dots in subdirectories to refer to the top-level command, and then calls to
Well let's fix autoconf then.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: A thought on urgency
Seth R Arnold [EMAIL PROTECTED] wrote:
Maybe this is compelling reason to keep the current Priority field
around; humans read one, machines read the other. (And Humans that care
Why should the serial field be in control? Wouldn't changelog be a better
place for it?
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#69031: ITP netkit-timed new virtual package time-daemon
Package: debian-policy
Version: 3.2.0.0
I'd like to package netkit-timed, YATD. In order to do that, we'll need to
have a new virtual package so that the various time daemons won't step on
each other's toes. I propose that it be called time-daemon.
Once that is on the list of virtual packages, the two existing time daemons
should provide conflict with it instead of conflicting with each other as
they do now.
Of course, I'd much rather have a good mechanism for all of them to coexist,
with only one running at anytime, but since we don't have such a beast,
they'll have to conflict for now.
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#55730: Updating policy
Wichert Akkerman [EMAIL PROTECTED] wrote:
I miss my proposal to use dpkg-shlibdeps for libraries as well. It's
quite essential for woody, since the CVS dpkg doesn't use ldd anymore
but objdump.
I was away at the time so I missed that one. Anyway, I second it.
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Bug#66535: proposal of virtual package: syslogd
Chris Waters [EMAIL PROTECTED] wrote:
names: ftp-server, not ftpd, or c-compiler, not cc. I'd rather have
the virtual package be named system-log-daemon. Just a suggestion.
Personally I prefer syslog-daemon.
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Parseable copyright files
Chris Waters [EMAIL PROTECTED] wrote:
Copyright: Joe Programmer and Bob Hacker, 1996-1999
What if you have as many copyright holders as dosemu?
Copyright (C) 1992 Krishna Balasubramanian
Copyright (C) 1990,1991,1992,1993 Carnegie Mellon University
Copyright (C) 1992,1994 John E. Davis
Copyright (C) 1993 David Dawes [EMAIL PROTECTED]
Copyright (C) 1995 Bjorn Ekwall [EMAIL PROTECTED]
Copyright (C) 1992 Tommy Frandsen
Copyright (C) 1991 IBM Corporation
Copyright (C) 1995 Hans Lermen [EMAIL PROTECTED]
Copyright (C) 1995 Dong Liu [EMAIL PROTECTED]
Copyright (C) 1994 Lutz Molgedey [EMAIL PROTECTED]
Copyright (C) 1986 Peter Norton
Copyright (C) 1993 Kenneth Osterberg
Copyright (C) 1995 Mark Rejhon [EMAIL PROTECTED]
Copyright (C) 1990,1991 Thomas Roell
Copyright (C) 1993 Robert Sanders [EMAIL PROTECTED]
Copyright (C) 1994 J. Lawrence Stephan [EMAIL PROTECTED]
Copyright (C) 1991,1992 Ian Lance Taylor
Copyright (C) 1991,1992,1994 Linus Torvalds
Copyright (C) 1992,1993,1994 Andrew Tridgell
Copyright (C) 1992 Theodore Ts'o
Copyright (C) 1994 University of Bristol, England
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Finger daemons in Debian should use a virtual package
Radovan Garabik [EMAIL PROTECTED] wrote:
It would not be better. I had to add the Conflict line because otherwise
you would install efingerd over (e.g.) cfinger, and either it would
remove cfinger from /etc/inetd.conf, and when you removed cfinger it
happily deleted efingerd entry, or it could leave cfinger entry alone, and
you have to modify it manually - not good.
That just means efingerd's postinst is broken.
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Finger daemons in Debian should use a virtual package
On Mon, May 22, 2000 at 11:43:51AM +0200, Radovan Garabik wrote:
no, it's cfingerd that it broken - it happily removes entries, not noticing
if they were made by cfingerd or anything else (at least did when I was
packaging efingerd, a long time ago)
Or is this preferrable behaviour?
That doesn't seem to correspond to what's in cfingerd's prerm. Although
it is buggy in that it shouldn't enable itself if there's already a finger
service there.
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Finger daemons in Debian should use a virtual package
On Mon, May 22, 2000 at 01:16:03PM +0200, Josip Rodin wrote:
You can't remove your entry selectively: update-inetd --remove will remove
all finger-related entries, because the --pattern option doesn't work with
--remove. Funny thing is, it doesn't abort with an error because of false
arguments, it just silently ignores it and continue.
Wrong. the argument to --remove is the pattern.
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Finger daemons in Debian should use a virtual package
On Mon, May 22, 2000 at 01:25:06PM +0200, Radovan Garabik wrote:
after uninstalling both fingerd and cfingerd my /etc/inetd.conf contains:
#:INFO: Info services
finger stream tcp nowait nobody /usr/sbin/tcpd
/usr/sbin/in.fingerd
#off# finger stream tcp nowait root/usr/sbin/tcpd
/usr/sbin/cfingerd
This is broken. You should never have anything commented out with #off#
unless the package in question is in an unconfingured state.
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Finger daemons in Debian should use a virtual package
On Mon, May 22, 2000 at 09:28:35PM +1000, Herbert Xu wrote:
On Mon, May 22, 2000 at 01:25:06PM +0200, Radovan Garabik wrote:
after uninstalling both fingerd and cfingerd my /etc/inetd.conf contains:
#:INFO: Info services
finger stream tcp nowait nobody /usr/sbin/tcpd
/usr/sbin/in.fingerd
#off# finger stream tcp nowait root/usr/sbin/tcpd
/usr/sbin/cfingerd
This is broken. You should never have anything commented out with #off#
unless the package in question is in an unconfingured state.
OK, what I said wasn't relevant here. This is indeed a long-standing
missing feature/bug in update-inetd, namely that it won't add another service
if there is already one in inetd.conf (#24043).
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Finger daemons in Debian should use a virtual package
On Sun, May 21, 2000 at 04:13:43PM +0200, Josip Rodin wrote:
Since there's not much point in running a fingerd on a non-standard port (at
least I haven't seen done anywhere, or a finger program that can query
different ports), it would seem appropriate to make these packages provide
and conflicts with a virtual package called `finger-server', i.e. add this
to the control file:
Provides: finger-server
Conflicts: finger-server
You do realise that with this change, all finger daemons except one will
have to be lowered to the priority of extra?
Anyway, it seems to be a pointless change for potato.
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Bug#63368: libglide2-v3: Unsatisified Dependancy
Manoj Srivastava [EMAIL PROTECTED] wrote:
Joseph == Joseph Carter [EMAIL PROTECTED] writes:
Joseph device3dfx-source builds device3dfx-module. Since you NEED
Joseph THAT MODULE in order to use Glide for the Voodoo3, the
Joseph dependency BELONGS THERE. It is not my problem that the
Joseph maintainer of that package chooses not to build the module
Joseph for standard kernels.
Have you considered asking the maintainer? And I think it
would make more sense to redirect these reports as a (perhaps
wishlist) bug against device3dfx-source asking for binary modules for
standard kernels.
This is probably off-topic for debian-policy, but dependencies is not
particularly useful for kernel modules. What should happen in this case
is that the library (or the calling program if the interface permits)
should produce a helpful message when /dev/3dfx cannot be opened
(hopefully it already does so in the case where it does not exist) because
of ENODEV.
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
