Processed: Close accepted policy amendments
Processing commands for [EMAIL PROTECTED]: close 21969 Bug#21969: [ACCEPTED 1998/05/01] Policy clarification about Standards-Version Bug closed, ack sent to submitter - they'd better know why ! close 28747 Bug#28747: [ACCEPTED 1999/04/05] Policy note that GPL moved to /usr/share/common-licenses Bug closed, ack sent to submitter - they'd better know why ! close 37257 Bug#37257: [ACCEPTED 1999/05/04] Libtool archive (*.la) files in -dev' packages Bug#37338: [ACCEPTED 1999/05/04] Libtool archive (*.la) files in -dev' packages Bug closed, ack sent to submitter - they'd better know why ! close 37338 Bug#37338: [ACCEPTED 1999/05/04] Libtool archive (*.la) files in -dev' packages Bug is already closed, cannot re-close. close 37342 Bug#37342: [ACCEPTED 1999/04/28] Logrotation Bug closed, ack sent to submitter - they'd better know why ! close 37345 Bug#37345: [ACCEPTED 1999/05/09] Adopt the FHS in place of FSSTND Bug closed, ack sent to submitter - they'd better know why ! close 37389 Bug#37389: [ACCEPTED 1999/05/09] Utmp group proposal Bug closed, ack sent to submitter - they'd better know why ! close 37713 Bug#37713: [ACCEPTED 1999/05/15] Separate menu policy (like virtual package list) Bug closed, ack sent to submitter - they'd better know why ! close 38212 Bug#38212: [ACCEPTED 1999/05/23] Rewrite of section 5.7 (Programs for the X Window System) Bug closed, ack sent to submitter - they'd better know why ! thanks Stopping processing here. Please contact me if you need assistance. Darren Benham (administrator, Debian Bugs database)
Bug#41729: marked as done ([REJECTED] Modify dpkg-buildpackage to handle FHS move)
Your message dated Tue, 26 Oct 1999 01:12:11 +0100 (BST)
with message-id [EMAIL PROTECTED]
and subject line Bug#41729: [PROPOSAL] Modify dpkg-buildpackage to handle FHS
move
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Darren Benham
(administrator, Debian Bugs database)
--
Received: (at submit) by bugs.debian.org; 21 Jul 1999 19:14:56 +
Received: (qmail 5658 invoked from network); 21 Jul 1999 19:14:56 -
Received: from serv1.is2.u-net.net (HELO mserv1b.u-net.net) (195.102.240.137)
by master.debian.org with SMTP; 21 Jul 1999 19:14:56 -
Received: from [195.102.197.149] (helo=polya)
by mserv1b.u-net.net with esmtp (Exim 2.10 #61)
id 1171oQ-0003qz-00
for [EMAIL PROTECTED]; Wed, 21 Jul 1999 20:13:55 +0100
Received: from jdg by polya with local (Exim 2.05 #1 (Debian))
id 116yGO-00057Y-00; Wed, 21 Jul 1999 16:26:32 +0100
Subject: [PROPOSAL] Modify dpkg-buildpackage to handle FHS move
To: [EMAIL PROTECTED] ( Debian bug reports)
Date: Wed, 21 Jul 1999 16:26:32 +0100 (BST)
X-Mailer: ELM [version 2.4ME+ PL48 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2241
Message-Id: [EMAIL PROTECTED]
From: Julian Gilbey [EMAIL PROTECTED]
Package: debian-policy
Version: 3.0.0.0
Severity: wishlist
Manoj requested that I submit this as a separate proposal so that it
doesn't get lost.
The following was originally posted on the thread discussing the
/usr/doc - /usr/share/doc move and the problems associated with it.
Julian
- Original message -
Maybe I can suggest an alternative which will
- not require packages to add anything to their maintainer scripts
- not break the majority of packages, and
- not create a forest of symlinks (which might be problematic, as has
been pointed out)
The dpkg-buildpackage program (and maybe autobuilders as well?) could
be modified so that after the .deb is built, before anything is signed
or similar, something like the following is done (within any necessary
fakeroot-type environment, of course):
if dpkg -c ../$pva.deb | grep usr/doc/; then
cat 2 -EOF
I see that you are using the old FSSTND /usr/doc directory.
I will attempt to move /usr/doc to /usr/share/doc, but please
modify your package in order to make it FHS compliant.
EOF
dpkg -x ../$pva.deb ${TMPDIR-/tmp}/$pva
dpkg -e ../$pva.deb ${TMPDIR-/tmp}/$pva/DEBIAN
mv ${TMPDIR-/tmp}/$pva/usr/doc ${TMPDIR-/tmp}/$pva/usr/share/doc
dpkg --build ${TMPDIR-/tmp}/$pva ..
fi
This would therefore only require one package to be upgraded in order
to handle most packages (even if it is dpkg!), and autobuilders could
recompile most packages automatically.
This would fail if any of the following happen:
- the package contained any symlinks (relative or absolute) to
/usr/doc, although the package would still build in such a case
- the maintainer scripts made assumptions about /usr/doc existing;
this will hopefully not affect too many packages.
Using this, I could feasibly see all packages becoming /usr/share/doc
using by the time potato is released, as the individual packages won't
directly need modification in order to make them FHS compliant.
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer, see http://www.debian.org/~jdg
- End of original message -
---
Received: (at 41729-done) by bugs.debian.org; 26 Oct 1999 00:28:47 +
Received: (qmail 22488 invoked from network); 26 Oct 1999 00:28:41 -
Received: from mserv1b.u-net.net (195.102.240.137)
by master.debian.org with SMTP; 26 Oct 1999 00:28:41 -
Received: from [195.102.196.30] (helo=polya)
by mserv1b.u-net.net with esmtp (Exim 2.10 #63)
id 11fuUe-0003C5-00
for [EMAIL PROTECTED]; Tue, 26 Oct 1999 01:29:40 +0100
Received: from jdg by polya with local (Exim 3.03 #1 (Debian))
id 11fuDj-0007Lf-00; Tue, 26 Oct 1999 01:12:11 +0100
Subject: Bug#41729: [PROPOSAL] Modify dpkg-buildpackage to handle FHS move
To: [EMAIL PROTECTED]
Date: Tue, 26 Oct 1999 01:12:11 +0100 (BST)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: [EMAIL PROTECTED]
From: Julian Gilbey [EMAIL PROTECTED]
This was rejected.
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept
Bug#48247: echo -n
On Mon, Oct 25, 1999 at 10:06:24PM +1000, Herbert Xu wrote: Let me state once again, this has no bearing whatsoever over the proposed change in policy and my question about whether escape codes/-e are to be mentioned or not. It is for purely pendantic value. On Mon, Oct 25, 1999 at 08:09:13PM -0400, Raul Miller wrote: I think it's an important point, because getting it wrong would have all sorts of nasty implications. On Tue, Oct 26, 1999 at 10:11:50AM +1000, Herbert Xu wrote: But do you agree that with your current proposal, you still have to fix all scripts that use -e/escape codes? Like I said before, I don't think this issue is relevant to debian policy. People can fix them, or not, depending on circumstances. Not precisely -- it means that there are no options required by POSIX. If we went with your interpretation, it would violate POSIX to provide any options for a command which weren't present in the POSIX synopsis. I would agree with you on this point for anything but echo. I don't think this reasoning applies here given what's in the Operands section and what the rationale is. It seems to be clear to me that the intention was to not allow any options, i.e., to make sure that all implementations of echo echo all of its arguments unless the first operand was -n. I would agree with you on this point except that's not what POSIX says. -- Raul
Processed: policy administrivia
Processing commands for [EMAIL PROTECTED]: retitle 46522 [PROPOSED] Simplified definition of Non-free Bug#46522: [EMAIL PROTECTED]: Re: SSH never free] Changed Bug title. severity 46522 wishlist Bug#46522: [PROPOSED] Simplified definition of Non-free Severity set to `wishlist'. retitle 48247 [PROPOSED] /bin/sh needs echo -n Bug#48247: echo -n Changed Bug title. End of message, stopping processing here. Please contact me if you need assistance. Darren Benham (administrator, Debian Bugs database)
Bug#48247: echo -n
On Mon, Oct 25, 1999 at 10:12:03PM -0400, Raul Miller wrote:
On Tue, Oct 26, 1999 at 10:11:50AM +1000, Herbert Xu wrote:
But do you agree that with your current proposal, you still have to fix all
scripts that use -e/escape codes?
Like I said before, I don't think this issue is relevant to debian
policy. People can fix them, or not, depending on circumstances.
OK, so basically what you're saying is you won't object to me filing reports
against packages that use echo -e/escape codes in #!/bin/sh scripts. In that
case, I hope that by the time we do the next release after potato, we will
have got rid of all -e/escape codes in Debian.
PS Here are a few packages that use -e/escape codes in #!/bin/sh scripts:
bison, debianutils, dpkg, kbd, libc6, login, util-linux. I found these just
by grepping pre*/post* scripts.
--
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: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 12:14:19AM +0100, Julian Gilbey wrote: Just a question which I haven't thoroughly investigated yet: I'm about to add #41232 (source dependencies) to the next policy version. But will this break existing tools? In particular, will the dpkg* tools yet be able to build a package using a Source-Depends: field, or will they die? If the latter, then we need a dpkg NMU (Wichert? Ben?) before this can be placed in policy. Ughh, this is completely different that what I was told. I see no problem with implementing this as written however. Just tell me that it wont change anymore before being implemented? :) As a helpful aside, could you send me a real simple shake down of what the fields are, where they need to go (after dpkg-gencontrol and/or dpkg-source get's done parsing them). Thanks, Ben
Re: Source dependencies: are we ready?
At 00:14 +0100 1999-10-26, Julian Gilbey wrote: Just a question which I haven't thoroughly investigated yet: I'm about to add #41232 (source dependencies) to the next policy version. But will this break existing tools? In particular, will the dpkg* tools yet be able to build a package using a Source-Depends: field, or will they die? If the latter, then we need a dpkg NMU (Wichert? Ben?) before this can be placed in policy. wtf? when did the proposal change to Source-Depends:? there's no evidence of that in the logs. -- Joel Klecker (aka Espy)Debian GNU/Linux Developer URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED] URL:http://web.espy.org/ URL:http://www.debian.org/
Bug#43651: ACCEPTED] mailbox locking
On Mon, 25 Oct 1999, Julian Gilbey wrote: I am about to include this amendment in policy. However, I am stuck with the wording, as you say the following. Questions: What version number should be used in footnote 2? What do we do with the reference implementation? Good question. I didn't hear from Miquel van Smoorenburg (the maintainer of liblockfile) since 1999-09-21. In his last mail he thought about different way how to implement the changed the behavior in liblockfile (by completely changing the API or by leaving the fcntl() part to the calling program). So I think we should change the above paragraph to something which explicitly says, how locking has to be implemented: All Debian MUAs, MTAs, MDAs and other mailbox accessing programs (like IMAP daemons) have to lock the mailbox in a NFS-safe way. This means that fcntl() locking has to be combined with dot locking. To avoid dead locks, a program has to use fcntl() first and dot locking after this or alternatively implement the two locking methods in a non blocking way[1]. Using the functions `maillock' and `mailunlock' provided by the `liblockfile*'[2] packages is the recommended way to realize this. Footnotes: [1] If it is not possible to establish both locks, the system shouldn't wait for the second lock to be established, but remove the first lock, wait a (random) time, and start over locking again. [2] liblockfile version = (fill in a version number here, which implements the above noted non blocking mechanism without blocking). Maybe we should say liblockfile version 1.01 until there is no new version available yet? Miquel, what are you thinking about this? Ciao Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ *
Re: Source dependencies: are we ready?
At 00:14 +0100 1999-10-26, Julian Gilbey wrote: Just a question which I haven't thoroughly investigated yet: I'm about to add #41232 (source dependencies) to the next policy version. But will this break existing tools? In particular, will the dpkg* tools yet be able to build a package using a Source-Depends: field, or will they die? If the latter, then we need a dpkg NMU (Wichert? Ben?) before this can be placed in policy. wtf? when did the proposal change to Source-Depends:? there's no evidence of that in the logs. Sorry, I was doing things from memory. The proposal says: + p +This is done using the ttBuild-Depends/tt, +ttBuild-Depends-Indep/tt, ttBuild-Conflicts/tt, and +ttBuild-Conflicts-Indep/tt control file fields. + /p and that is, of course, what I was going to use. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 12:15:52AM -0700, Joel Klecker wrote: wtf? when did the proposal change to Source-Depends:? there's no evidence of that in the logs. *My* proposal has never changed that way (#41232). The fields are: Build-Depends: Build-Depends-Indep: Build-Conflicts: Build-Conflicts-Indep: -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Bug#34610: unsuffixed shared libraries
What's the current status of this bug report? How will we deal with this problem? Julian MICO (www.mico.org) doesn't use so versions, but always puts the full version into the library file name. An example result of ldd is: coolo:~ ldd /usr/bin/idl libmico2.2.3.so = /usr/lib/libmico2.2.3.so (0x4001b000) I'd say that's a mico bug. It should not do that. Someone hasn't understood how shared libraries work. I don't think any other package should be changed to cope with this particular misbehaviour. Why should this be a misbehaviour? If you do it that way, you make sure that it the version dependencies work on every system even with static libraries. It may be that this is unusual, but I can't see this as a bug of mico! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Bug#35510: mirror license seems Debian-specific
Any progress on this bug report? Summary of the bug report: If mirror license is not Debian-specific, its license should explicitly allow distribution of the program in modified form, by point #4 in the DFSG. The maintainer asked the author about being ok that *Debian* distributes mirror as a .deb and as a .orig plus .diff. IMHO, the way the question was formulated makes the ok from the author to be Debian-specific, but the maintainer disagrees. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Bug#37254: dpkg: update-alternatives madness
I agree that update-alternatives shouldn't put an alternative into manual mode because a _target_ disappeared unexpectedly. I'll look into this eventually. But, the problem doesn't happen if you call update-alternatives in the prerm, which is where you should. So it would be good if the policy manual could be changed to this effect. Therefore, I've reassigned this bug to debian-policy, dpkg. When the policy is changed, please assign it back to dpkg. Thanks, Ian. Now the packaging manual already states: Each package provides its own version under its own name, and calls update-alternatives in its postinst to register its version (and again in its prerm to deregister it). Do we need to then specify this in the policy manual, or will it be sufficient to file bugs against packages which don't have the needed update-alternatives in their prerm? Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Bug#41902: Test suite proposal
I am currently sorting through the bugs in debian-policy, and came across this one by Ian Jackson. Any thoughts? Julian I think most of us will agree that we need some kind of way of distributing and automatically using regression test suites. We need to do this in a way that allows people to download just the .deb and the regression tests, without the full source archive, and we need to do it in a way that support automatic tests of various kinds. Regression tests for many of our programs will be hard to execute under some circumstances, because they may want to be root, change configurations of things, etc. I suggest that we come up with a standard scheme for (a) distributing the tests and (b) expressing which ones are appropriate to run. Regarding (a), I think a separate part of the source package is appropriate. I suggest package_version.tests.tar.gz which contains a directory package-version-tests/ This is supposed to work when unpacked anywhere. Inside package-version-tests there should be some indication of what tests are available. I suggest a directory `controls' or some such, containing one file per test. Each file would contain some basic information about the test: * Whether it needs to run as any particular user, and if so which. * How much change it will make to the system, chosen from perhaps - none visible - reconfigure or change systemwide data belonging to the package in question or some closely related package (scorefiles, logfiles etc. do not count unless they're deleted or stuffed full of junk) - reconfigure or change systemwide configuration belonging to other packages, or shared between packages. This includes randomly installing other packages (except test packages if they are harmless and are removed again afterwards). It also includes rebooting the machine or anything like that. * Whether the test is supposed to work given only the package and its dependencies, or whether it would need the Recommends as well. * Whether the test requires a tty and/or an X display, and whether it interacts with the user. (NB a package may be noninteractive but require X and/or a tty). * Other package(s) which must be installed for the test to be meaningful, or which must not be installed. (Depends/Conflicts) * Any other things we think are relevant here. The format must be extensible. * A shell script to run. The current directory will be set to the base of the test suite. The test script is allowed to use any file in the test suite, and is allowed to create files etc. inside the test suite. The test is considered to have succeeded if this script exits with a zero exit status and without printing anything on stderr. There should also be a `cleanups' directory in the same format, but whose scripts just clean up the side-effects of the tests (even if the tests failed), if possible. This includes deleting any files the tests created. To assist in writing test scripts, there should perhaps be support package(s) which contain useful utilities for (eg) applying regexps to the output of things, etc. Ian. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Bug#26995: marked as done ([BUG] problem viewing fsstnd-1.2.dvi.gz)
Your message dated Tue, 26 Oct 1999 11:05:49 +0100 (BST) with message-id [EMAIL PROTECTED] and subject line Bug#26995: fsstnd-1.2.dvi.gz is wrong has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Darren Benham (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 23 Sep 1998 11:06:59 + Received: (qmail 21426 invoked from network); 23 Sep 1998 11:06:58 - Received: from kubota.rcpom.osaka-u.ac.jp ([EMAIL PROTECTED]) by master.debian.org with SMTP; 23 Sep 1998 11:06:58 - Received: from localhost (really [127.0.0.1]) by kubota.rcpom.osaka-u.ac.jp via smail with esmtp (ident kubota using rfc1413) id [EMAIL PROTECTED] (Debian Smail3.2.0.101) for [EMAIL PROTECTED]; Wed, 23 Sep 1998 20:34:50 +0900 (JST) To: [EMAIL PROTECTED] Subject: fsstnd-1.2.dvi.gz is wrong. X-Mailer: Mew version 1.93 on Emacs 20.3 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: [EMAIL PROTECTED] Date: Wed, 23 Sep 1998 20:34:45 +0900 From: Tomohiro KUBOTA [EMAIL PROTECTED] X-Dispatcher: imput version 980905(IM100) Lines: 7 Package: debian-policy Version: 2.4.1.4 Large black blocks (large characeters?) sometimes appear in the TeX Version of fsstnd-1.2 and they hide the page. So I can't read such parts. --- Received: (at 26995-done) by bugs.debian.org; 26 Oct 1999 10:40:31 + Received: (qmail 13241 invoked from network); 26 Oct 1999 10:40:28 - Received: from mserv1b.u-net.net (195.102.240.137) by master.debian.org with SMTP; 26 Oct 1999 10:40:28 - Received: from [195.102.196.69] (helo=polya) by mserv1b.u-net.net with esmtp (Exim 2.10 #63) id 11g42j-0005CS-00 for [EMAIL PROTECTED]; Tue, 26 Oct 1999 11:41:30 +0100 Received: from jdg by polya with local (Exim 3.03 #1 (Debian)) id 11g3UD-0007rl-00; Tue, 26 Oct 1999 11:05:49 +0100 Subject: Bug#26995: fsstnd-1.2.dvi.gz is wrong To: [EMAIL PROTECTED] Date: Tue, 26 Oct 1999 11:05:49 +0100 (BST) X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: [EMAIL PROTECTED] From: Julian Gilbey [EMAIL PROTECTED] Tomohiro Large black blocks (large characeters?) sometimes appear Tomohiro in the TeX Version of fsstnd-1.2 and they hide the page. Tomohiro So I can't read such parts. Could you give more details? Like what pages this occurs on? Do you see this in xdvi, or is it in the printed output? However, I must confess that this seems more like a problem with your TeX processing environment than with the fsstnd, since I don't see the fsstnd doing anything special with fonts. I just viewd the dvi file using xdvi, and I do not see anything like what you report. I used two dvi drivers on Windows95 -- WinDviPro (Impress, a Japanese company, sells this) and dviout for Windows (a free software). Both of them are Japanese software and support pTeX and JTeX, Japanese extension of TeX which are upper compatible to ordinal TeX. If fsstnd-1.2.dvi uses some other extension, it is likely that the extensition and Japanese extension conflicts. But I will consult with Japanese Debian users to find what is responsible. Tomohiro Kubota (a) We no longer use fsstnd. (b) We don't try to find bugs in Windows software. (c) Nothing's been heard on this bug report for 13 months from the submitter. (d) There are some 'special's in the DVI file which may have been causing the problems. (e) The PostScript/PDF version of a file is usually much more reliable that the DVI version for this reason. For all of these reasons, I'm closing this bug report. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 09:52:09AM +0100, Julian Gilbey wrote: At 00:14 +0100 1999-10-26, Julian Gilbey wrote: Just a question which I haven't thoroughly investigated yet: I'm about to add #41232 (source dependencies) to the next policy version. But will this break existing tools? In particular, will the dpkg* tools yet be able to build a package using a Source-Depends: field, or will they die? If the latter, then we need a dpkg NMU (Wichert? Ben?) before this can be placed in policy. wtf? when did the proposal change to Source-Depends:? there's no evidence of that in the logs. Sorry, I was doing things from memory. The proposal says: + p +This is done using the ttBuild-Depends/tt, +ttBuild-Depends-Indep/tt, ttBuild-Conflicts/tt, and +ttBuild-Conflicts-Indep/tt control file fields. + /p Ok, this is what I have as recognized fields in the current dpkg CVS. The wording in that new proposal for bug #41232 through me for a loop. Anyway, all that is left to be done for dpkg is have dpkg-buildpackage (and possibly dpkg-source?) do something when the build depends aren't satisfied. Just so I don't have to go looking all over creation, what was the general consensus on how dpkg-* scripts should handle and react to these fields? Ben
Re: Uploaded alsadriver-unstable 0.5pre+cvs19991024+1855-1 (source all) to master
On Tue, 26 Oct 1999, Masato Taruishi wrote: At Mon, 25 Oct 1999 23:11:18 +0200 (MET DST), Gergely Madarasz [EMAIL PROTECTED] wrote: alsadriver-unstable (0.5pre+cvs19991024+1855-1) unstable; urgency=low . * new upstream release. * Changed section from main to contrib. Why change the sections ? Does it depend on non-free or non-us or other contrib software ? Because that is the only case when it should be put into contrib. The reason why I put it into contrib is that I believe it is too unstable to put it into main section. There is the following sentence in debian then put it into project/experimental policy manual 2.1.3: * packages which we don't want to support because they are too buggy, Is this a wrong change? Hmm... indeed... I thought we sorted this out in the policy already. Btw your policy manual version is a bit outdated. Greg
Bug#42052: var/spool/mail and /var/mail
On Tue, 26 October 1999 11:39:06 +0100, Julian Gilbey wrote: We spent a lot of time on this list thrashing out the /var/spool/mail vs. /var/mail issue. It would be a shame if it came to nothing due to a lack of seconds. Please check up this final proposal (included below) and second it if you think it appropriate. Was that a second by you? ;-) I also second this proposal. The change would have to be in the bootdiscs first, right? Alexander
Bug#46522: another second
I hereby also second the proposal. Alexander -- - Real programmers don't comment their code. If it was hard to write, it should be hard to understand. Alexander Koch - - WWJD - aka Efraim - PGP 0xE7694969 - ARGH-RIPE
Re: Source dependencies: are we ready?
At 00:14 +0100 1999-10-26, Julian Gilbey wrote:
Just a question which I haven't thoroughly investigated yet:
I'm about to add #41232 (source dependencies) to the next policy
version. But will this break existing tools? In particular, will the
dpkg* tools yet be able to build a package using a Source-Depends:
field, or will they die? If the latter, then we need a dpkg NMU
(Wichert? Ben?) before this can be placed in policy.
The tools ignore fields that they don't understand. However, dpkg-dev
does need to be modified to know the fields specifically or it will
not pass them through from the control file (which is done in dpkg
CVS).
I do have a problem with the text for policy; it does not explain the
difference between Build-Indep-{Depends,Conflicts} and
Build-{Depends,Conflicts}.
I don't have a clear idea of the difference, and I participated in
the discussion of the proposal.
Someone who simply reads the new policy will have no clue (besides
perhaps guessing that the -Indep form has some relation to
binary-indep) what exactly the difference is and in what situations
each is used.
--
Joel Klecker (aka Espy)Debian GNU/Linux Developer
URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED]
URL:http://web.espy.org/ URL:http://www.debian.org/
Re: Source dependencies: are we ready?
At 06:31 -0400 1999-10-26, Ben Collins wrote: On Tue, Oct 26, 1999 at 09:52:09AM +0100, Julian Gilbey wrote: Sorry, I was doing things from memory. The proposal says: + p +This is done using the ttBuild-Depends/tt, +ttBuild-Depends-Indep/tt, ttBuild-Conflicts/tt, and +ttBuild-Conflicts-Indep/tt control file fields. + /p Ok, this is what I have as recognized fields in the current dpkg CVS. The wording in that new proposal for bug #41232 through me for a loop. Anyway, all that is left to be done for dpkg is have dpkg-buildpackage (and possibly dpkg-source?) do something when the build depends aren't satisfied. There's also the extended syntax for the fields, it is possible to specify architecture. e.g. for glibc: Build-Depends: kernel-headers-2.2.12 [!hurd-i386 !m68k], kernel-headers-2.2.10 [m68k], hurd-dev [hurd-i386], gnumach-dev [hurd-i386], mig [hurd-i386] It'd be cool to have dpkg proper support this syntax too. -- Joel Klecker (aka Espy)Debian GNU/Linux Developer URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED] URL:http://web.espy.org/ URL:http://www.debian.org/
Re: Source dependencies: are we ready?
Previously Julian Gilbey wrote: I'm about to add #41232 (source dependencies) to the next policy version. But will this break existing tools? Yes. And I won't think I want to change dpkg and friends to accept the fields until someone comes up with a complete implementation. I'm annoyed though, that everyone is completely ignoring a *working* implementation of source-dependencies simply because nobody is willing to clean it up a little and package it. How can that happen??? Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | pgpdRsd1kcaf6.pgp Description: PGP signature
Bug#37254: dpkg: update-alternatives madness
Previously Julian Gilbey wrote: Do we need to then specify this in the policy manual, or will it be sufficient to file bugs against packages which don't have the needed update-alternatives in their prerm? No need to put this in the policy manual. The policy manual is for policies, not for guidelines to make packages. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | pgpD9LZXC9jec.pgp Description: PGP signature
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 01:54:58PM +0200, Wichert Akkerman wrote: Yes. And I won't think I want to change dpkg and friends to accept the fields until someone comes up with a complete implementation. How do you define complete implementation? The build daemon folks have had a working implementation for ages, all that needs to be done is to get that system to parse these fields. I'm annoyed though, that everyone is completely ignoring a *working* implementation of source-dependencies simply because nobody is willing to clean it up a little and package it. How can that happen??? What are you talking about? -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 04:30:50AM -0700, Joel Klecker wrote:
I do have a problem with the text for policy; it does not explain the
difference between Build-Indep-{Depends,Conflicts} and
Build-{Depends,Conflicts}.
The difference is clearly defined by the amendment. The
Build-{Depends,Conflicts}-Indep fields will be consulted only when the
architecture-independent packages are being built. In other words, they
will *not* be consulted when doing a architecture-dependent packages only
build (for example, like the build daemons do).
Someone who simply reads the new policy will have no clue (besides
perhaps guessing that the -Indep form has some relation to
binary-indep) what exactly the difference is and in what situations
each is used.
Here's a rule of thumb: if your source package builds only
architecture-dependent packages, use only Build-{Depends,Conflicts}.
If it builds only architecture-independent packages, you get too choose.
If it builds both, use Build-{Depends,Conflicts} to specify build-time
dependencies needed to build the architecture-dependent packages and
put in Build-{Depends-Conflicts}-Indep whatever additional packages are
needed to build the architecture-independent packages.
I really wish you had spoken up back then when we could have made the
wording more clear on this.
--
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
(John Cage)
Bug#43724: experimental patch for very much faster dpkg -R
It seems that this proposal was rejected due to dpkg -iGROEB being superceded by apt-cdrom. Is this correct? Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Bug#43928: libc and kernel source policy
This should certainly be discussed with the libc maintainers before
making such a proposal. I am sure that they did not take the decision
lightly.
I wish to change Debian policy regarding libc and the kernel sources.
The document /usr/share/doc/libc6/FAQ.Debian.gz states:
Occasionally, changes in the kernel headers cause problems with the
compilation of libc and of programs that use libc. To ensure that users
are not affected by these problems, we configure libc to use the headers
from a kernel that is known to work with libc and the programs that
depend on stable kernel headers.
The kernel headers don't change much these days on stable releases, yet
the Debian libc packages continue to carry with them full sets of kernel
headers (whatever somebody has _manually_ copied into place as
/usr/include/{linux,asm,scsi,etc} on the system building glibc).
Why in the heck do we have kernel-headers packages in Debian? Why
do we have kernel-source packages? It seems to me that if building
Kernel-headers packages might be unnecessary, given your argument.
Kernel-source, though: what planet are you on?
libc _requires_ a particular set of kernel include files (which I
consider to be dubious) why not have glibc _depend_ on a particular
kernel-headers-xxx package? Why not have kernel headers provide
/usr/include/{linux,asm,scsi,etc} (or at least put in symlinks
for them pointing to /usr/src/kernel-headers-xxx)?
Again, let's hear what the libc guys have to say before being too
radical.
That would be a great service to kernel hackers, libc hackers, and
mirror maintainers (since libc would no longer have to carry around
the extra baggage of kernel headers).
Not necessarily.
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Bug#44922: PROPOSAL] handling missing stuff in /usr/local
Proposed addition to 3.1.2: Because '/usr/local' and its contents are for exclusive use of the local administrator, a package must not rely on the presence or absence of files or directories in '/usr/local' for normal operation, although files present in there may modify or enhance the behavior of the package. I second the idea, but: I'm not sure how this fits in cleanly with the existing wording. Can I suggest the following instead: p If you do create a directory in tt/usr/local/tt for local additions to a package, you must ensure that settings in tt/usr/local/tt take precedence over the equivalents in tt/usr/tt./p + + p + However, because '/usr/local' and its contents are for + exclusive use of the local administrator, a package must + not rely on the presence or absence of files of + directories in '/usr/local' for normal operation./p p The tt/usr/local/tt directory itself and all the subdirectories created by the package should have permissions 2775 (group-writable and set-group-id) and be owned by ttroot.staff/tt./p /sect1 Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Source dependencies: are we ready?
I'm annoyed though, that everyone is completely ignoring a *working* implementation of source-dependencies simply because nobody is willing to clean it up a little and package it. How can that happen??? Aehm, what do you mean? For just getting src-deps working, it's only necessary that the appropriate fields are passed through (better without warnings :-) Ok, we wish that src-deps are also checked, but this isn't too hard (and IMHO it belongs into dpkg-source -x). sbuild (used by the build daemons) already understands src-deps in the control file. Do you consider this a working implementation? However, it's not packaged yet :-), but more because the whole buildd setup stuff is rather complicated. I've made some progress here lately, but it isn't finished yet. Roman
Bug#40742: marked as done ([PROPOSED] a new virtual package for FTP servers)
Your message dated Tue, 26 Oct 1999 15:36:43 +0200 with message-id [EMAIL PROTECTED] and subject line Bug#40742: Your policy proposal has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Darren Benham (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 4 Jul 1999 19:10:01 + Received: (qmail 10315 invoked from network); 4 Jul 1999 19:10:01 - Received: from murphy.debian.org (209.41.108.199) by master.debian.org with SMTP; 4 Jul 1999 19:10:00 - Received: (qmail 13670 invoked from network); 4 Jul 1999 19:04:46 - Received: from jagor.srce.hr ([EMAIL PROTECTED]) by murphy.debian.org with SMTP; 4 Jul 1999 19:04:46 - Received: (from [EMAIL PROTECTED]) by jagor.srce.hr (8.9.0/8.9.0) id VAA18047 for [EMAIL PROTECTED]; Sun, 4 Jul 1999 21:03:11 +0200 (MET DST) Date: Sun, 4 Jul 1999 21:03:11 +0200 From: Josip Rodin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: proftpd: needs to conflict only with old wu-ftpds Message-ID: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i Package: proftpd Hi, The Conflicts: wu-ftpd is incomplete, there should be a version, for example: Conflicts: wu-ftpd ( 2.5) Why? Because I just uploaded wu-ftpd 2.5.0, and they share no files :) TIA. -- enJoy -*/\*- spelled 'iosip', or simply 'joseph' --- Received: (at 40742-done) by bugs.debian.org; 26 Oct 1999 13:38:57 + Received: (qmail 19876 invoked from network); 26 Oct 1999 13:38:51 - Received: from jagor.srce.hr ([EMAIL PROTECTED]) by master.debian.org with SMTP; 26 Oct 1999 13:38:51 - Received: (from [EMAIL PROTECTED]) by jagor.srce.hr (8.9.0/8.9.0) id PAA08787; Tue, 26 Oct 1999 15:36:58 +0200 (MET DST) Date: Tue, 26 Oct 1999 15:36:43 +0200 From: Josip Rodin [EMAIL PROTECTED] To: Julian Gilbey [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Bug#40742: Your policy proposal Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: [EMAIL PROTECTED]; from Julian Gilbey on Tue, Oct 26, 1999 at 01:33:10AM +0100 On Tue, Oct 26, 1999 at 01:33:10AM +0100, Julian Gilbey wrote: You have submitted a proposed modification to the Debian Policy. I would be most grateful if you could check on the status of your proposal (at http://www.debian.org/Bugs/db/pa/ldebian-policy.html) and change the title/severity/forwarded status to indicate its present status, in anticipation of a forthcoming policy revision. [snip] Oh, yes, I submitted this one (#42) - as the 'bug report' is already fixed, according to Policy 3.0.1.1's virtual packages list changelog: 13 Jul 1999 Added ftp-server ...and I submitted it, I'll close it now. No point in having it open, eh? :) -- enJoy -*/\*- don't even try to pronounce my first name
Bug#34610: unsuffixed shared libraries
Julian Gilbey [EMAIL PROTECTED] wrote:
What's the current status of this bug report? How will we deal with
this problem?
How is this a bug in the policy? If upstream insists on new sonames for each
release. We must release packages with new names for each release as well.
There is no other choice since the new libraries won't satisfy the dependency
of old binaries.
--
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: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 04:18:55AM -0700, Joel Klecker wrote: At 06:31 -0400 1999-10-26, Ben Collins wrote: Ok, this is what I have as recognized fields in the current dpkg CVS. The wording in that new proposal for bug #41232 through me for a loop. Anyway, all that is left to be done for dpkg is have dpkg-buildpackage (and possibly dpkg-source?) do something when the build depends aren't satisfied. There's also the extended syntax for the fields, it is possible to specify architecture. e.g. for glibc: Build-Depends: kernel-headers-2.2.12 [!hurd-i386 !m68k], kernel-headers-2.2.10 [m68k], hurd-dev [hurd-i386], gnumach-dev [hurd-i386], mig [hurd-i386] It'd be cool to have dpkg proper support this syntax too. You don't ask much do you? :) I haven't tested it, but I think dpkg will simply apply the contents of the field verbatim. As for actually doing something with the info, that is going to take extra work. Has anyone else started on getting dpkg-buildpackage to make use of this info? I know that sbuild currently uses them (to what extent, I'm not sure). Ben
Bug#43928: libc and kernel source policy
On Tue, Oct 26, 1999 at 12:45:20PM +0100, Julian Gilbey wrote:
This should certainly be discussed with the libc maintainers before
making such a proposal. I am sure that they did not take the decision
lightly.
I wish to change Debian policy regarding libc and the kernel sources.
The document /usr/share/doc/libc6/FAQ.Debian.gz states:
Occasionally, changes in the kernel headers cause problems with the
compilation of libc and of programs that use libc. To ensure that users
are not affected by these problems, we configure libc to use the headers
from a kernel that is known to work with libc and the programs that
depend on stable kernel headers.
The kernel headers don't change much these days on stable releases, yet
the Debian libc packages continue to carry with them full sets of kernel
headers (whatever somebody has _manually_ copied into place as
/usr/include/{linux,asm,scsi,etc} on the system building glibc).
Given that they don't change much, what is the argument against having
static ones installed with libc-dev? Your argument tends to assert that there
is actually nothing wrong with this policy. Personally, I would hope that
it always stays this way. For the non-i386 archs, it makes for much less
bug reports, and more stable/consistent builds.
Perhaps the real argument should be, to have something that allows the
users to specify their own headers without libc-dev overwriting them.
Ben
Bug#43724: experimental patch for very much faster dpkg -R
Previously Julian Gilbey wrote: It seems that this proposal was rejected due to dpkg -iGROEB being superceded by apt-cdrom. Is this correct? I don't think so.. this was that patch that added an option to dpkg to use filenames instead of looking inside packages, right? Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | pgpswIqANs6OG.pgp Description: PGP signature
Build-depends = change policy wording
Given that there are now two sorts of depends, I am changing the paragraph: Packages may not depend on packages with lower priority values. If this should happen, one of the priority values will have to be adapted. to read: Binary packages may not depend on binary packages with lower priority values. If this should happen, one of the priority values will have to be adapted. This is consistent with the changed wording in the packaging manual introduced by the accepted proposal introducing build-time dependencies. Are there any objections? Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Packaging Manual is policy
Reading bug #31645, it seems clear that the Packaging Manual was accepted as policy, although Joey had reservations. Should I go ahead and make the modifications Manoj proposed? Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 04:30:50AM -0700, Joel Klecker wrote:
I do have a problem with the text for policy; it does not explain the
difference between Build-Indep-{Depends,Conflicts} and
Build-{Depends,Conflicts}.
I think you mean the packaging manual, and the diff says quite
clearly (or at least it would be if it weren't in SGML ;)
taglist
tagttBuild-Depends/tt, ttBuild-Conflicts/tt/tag
item
p
The ttBuild-Depends/tt and ttBuild-Conflicts/tt fields apply
to the targets
ttbuild/tt, ttbinary/tt, ttbinary-arch/tt
and ttbinary-indep/tt.
/p
/item
tagttBuild-Depends-Indep/tt, ttBuild-Conflicts-Indep/tt/tag
item
p
The ttBuild-Depends-Indep/tt and
ttBuild-Conflicts-Indep/tt fields apply to the
targets ttbinary/tt and ttbinary-indep/tt.
/p
/item
/taglist
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Bug#34223: APT removes essential packages.
Santiago indicated a contradiction between APT's behaviour and the packaging manual. Santiago: could you suggest a rewording of the packaging manual which would resolve this issue? Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Bug#37254: dpkg: update-alternatives madness
Previously Julian Gilbey wrote: Do we need to then specify this in the policy manual, or will it be sufficient to file bugs against packages which don't have the needed update-alternatives in their prerm? No need to put this in the policy manual. The policy manual is for policies, not for guidelines to make packages. Wichert. So I'm reassigning back to dpkg. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Bug#39398: debian-policy has an unclear statement on dependancies and priorities
In /usr/doc/debian-policy/policy.html/ch2.html it says: Packages may not depend on packages with lower priority values. If this should happen, one of the priority values will have to be adapted. I think this is unclear. Especially the second sentence. Perhaps this phraseology would be clearer: All dependencies in a package MUST have equal or higher priority than the package itself. In order to achieve this the priorities of one or more packages may have to be adjusted. I personally think that the original version is clearer. Dependencies could be misleading. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Bug#42554: A proposal for README.Debian
Has this proposal been effectively rejected? Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Processed: Reassign back to dpkg
Processing commands for [EMAIL PROTECTED]: reassign 37254 dpkg Bug#37254: dpkg: update-alternatives madness Bug reassigned from package `debian-policy, dpkg' to `dpkg'. thanks Stopping processing here. Please contact me if you need assistance. Darren Benham (administrator, Debian Bugs database)
Bug#29522: marked as done ([PROPOSED]: clarification needed about diversions)
Your message dated Tue, 26 Oct 1999 15:57:20 +0100 (BST) with message-id [EMAIL PROTECTED] and subject line Bug#29522: diversions has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Darren Benham (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 16 Nov 1998 15:15:56 + Received: (qmail 1521 invoked from network); 16 Nov 1998 15:15:56 - Received: from mail.cs.tu-berlin.de (130.149.17.13) by master.debian.org with SMTP; 16 Nov 1998 15:15:56 - Received: from bolero.cs.tu-berlin.de ([EMAIL PROTECTED] [130.149.19.1]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id QAA25804 for [EMAIL PROTECTED]; Mon, 16 Nov 1998 16:14:13 +0100 (MET) Received: (from [EMAIL PROTECTED]) by bolero.cs.tu-berlin.de (8.9.1/8.9.0) id QAA23239; Mon, 16 Nov 1998 16:14:11 +0100 (MET) From: Matthias Klose [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 16 Nov 1998 16:14:11 +0100 (MET) To: [EMAIL PROTECTED] Subject: diversions X-Mailer: VM 6.43 under 20.4 Emerald XEmacs Lucid Message-ID: [EMAIL PROTECTED] Package: packaging-manual Version: 2.4.1.2 are the examples for diversions are wrong, or do I miss something? dpkg-divert has to be called for an upgrade as well and for the purge of a package as well. if [ install = $1 ]; then dpkg-divert --package smailwrapper --add --rename \ --divert /usr/sbin/smail.real /usr/sbin/smail fi if [ remove = $1 ]; then dpkg-divert --package smailwrapper --remove --rename \ --divert /usr/sbin/smail.real /usr/sbin/smail fi --- Received: (at 29522-done) by bugs.debian.org; 26 Oct 1999 15:13:01 + Received: (qmail 17226 invoked from network); 26 Oct 1999 15:13:01 - Received: from mserv1b.u-net.net (195.102.240.137) by master.debian.org with SMTP; 26 Oct 1999 15:13:01 - Received: from [195.102.196.171] (helo=polya) by mserv1b.u-net.net with esmtp (Exim 2.10 #63) id 11g8IU-0005kX-00 for [EMAIL PROTECTED]; Tue, 26 Oct 1999 16:14:02 +0100 Received: from jdg by polya with local (Exim 3.03 #1 (Debian)) id 11g82K-0008Iq-00; Tue, 26 Oct 1999 15:57:20 +0100 Subject: Bug#29522: diversions To: [EMAIL PROTECTED] Date: Tue, 26 Oct 1999 15:57:20 +0100 (BST) X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: [EMAIL PROTECTED] From: Julian Gilbey [EMAIL PROTECTED] are the examples for diversions are wrong, or do I miss something? dpkg-divert has to be called for an upgrade as well and for the purge of a package as well. As was pointed out, the packaging manual is usually correct, so I'm closing this bug report. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Build-depends = change policy wording
On Tue, Oct 26, 1999 at 14:46:03 +0100, Julian Gilbey wrote: Are there any objections? This is not an objection, but I wish there were slightly more accurate term than binary package, because some binary packages don't contain binaries (e.g. just data and/or scripts). binary package could be misread in such a way as to be interpreted as those .debs that aren't arch-independent. Ray -- UNFAIR Term applied to advantages enjoyed by other people which we tried to cheat them out of and didn't manage. See also DISHONESTY, SNEAKY, UNDERHAND and JUST LUCKY I GUESS. - The Hipcrime Vocab by Chad C. Mulligan
Bug#43928: libc and kernel source policy
On Tue Oct 26, 1999 at 10:21:21AM -0400, Ben Collins wrote: Perhaps the real argument should be, to have something that allows the users to specify their own headers without libc-dev overwriting them. That was indeed the problem that caused my concern. When I am hacking on the kernel and/or working with development kernels, it is very inconveinient to have one's kernel headers removed fro /usr/include -Erik -- Erik B. Andersen Web:http://www.xmission.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons--
Bug#34223: APT removes essential packages.
reopen 34223 severity 34223 normal thanks On Tue, 26 Oct 1999, Julian Gilbey wrote: Santiago indicated a contradiction between APT's behaviour and the packaging manual. Santiago: could you suggest a rewording of the packaging manual which would resolve this issue? Simple answer: No, this is not my problem ;-) Detailed answer: I can suggest a rewording of the packaging manual which does not make it to deviate from its original spirit and makes APT behaviour almost-compliant to it. Packaging manual says: The install script should feed all the available .deb files to dpkg --iGOEB (this is equivalent to dpkg --install --refuse-downgrade --selected-only --skip-same-version --auto-deconfigure). The -R (--recursive) option for traversing subdirectories may also be useful here). I would suggest to add something like this: Clever dselect methods (for example, those who do package ordering) are allowed to do this differently if they do the same by other means. It should be understood or made explicit that removing an essential package is not doing the same, because you can't never remove an essential package by calling dpkg --iGOEB. I think Jason will not like this wording because it does not allow removing an essential package. I think APT should not allow the user to remove an essential package and packaging manual should not bless current APT behaviour, so, as I said before, I'm sorry but I'm unable to suggest a rewording of packaging manual which would resolve this issue. I still think this is a grave bug in APT. Thanks. -- 5768b48d9bee1cb407a4f4ca7c80e787 (a truly random sig)
Bug#43928: libc and kernel source policy
On Tue, Oct 26, 1999 at 09:40:57AM -0600, Erik Andersen wrote: On Tue Oct 26, 1999 at 10:21:21AM -0400, Ben Collins wrote: Perhaps the real argument should be, to have something that allows the users to specify their own headers without libc-dev overwriting them. That was indeed the problem that caused my concern. When I am hacking on the kernel and/or working with development kernels, it is very inconveinient to have one's kernel headers removed fro /usr/include Then could you note that by retitling the bug report, and making it priority wishlist? Ben
Processed: Re: Bug#34223: APT removes essential packages.
Processing commands for [EMAIL PROTECTED]: reopen 34223 Bug#34223: apt and packaging manual are in contradiction is already open, cannot reopen. severity 34223 normal Bug#34223: apt and packaging manual are in contradiction Severity set to `normal'. thanks Stopping processing here. Please contact me if you need assistance. Darren Benham (administrator, Debian Bugs database)
Processed: Dpkg can't decide these things
Processing commands for [EMAIL PROTECTED]: reassign 37254 packaging-manual Bug#37254: dpkg: update-alternatives madness Bug reassigned from package `dpkg' to `packaging-manual'. stop Stopping processing here. Please contact me if you need assistance. Darren Benham (administrator, Debian Bugs database)
Re: Build-depends = change policy wording
On Tue, 26 Oct 1999, Julian Gilbey wrote: Given that there are now two sorts of depends, I am changing the paragraph: Packages may not depend on packages with lower priority values. If this should happen, one of the priority values will have to be adapted. to read: Binary packages may not depend on binary packages with lower priority values. If this should happen, one of the priority values will have to be adapted. This is consistent with the changed wording in the packaging manual introduced by the accepted proposal introducing build-time dependencies. Are there any objections? Mmm, is this change really needed? *Source* packages do not have priorities... -- ec4eefc0f4a0d94b8fe7f2d9655dfafb (a truly random sig)
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 04:51:23PM +0200, Wichert Akkerman wrote:
Previously Antti-Juhani Kaijanaho wrote:
How do you define complete implementation?
A dpkg-source that:
a) supports build-dependencies
b) supports multiple patches
c) can setup a buildroot and start building everything that is needed to
build a package
Personally I don't think dpkg-source can enforce this. At the point of
unpacking, we don't even know what targets we are going to build (arch,
indep, both?). Dpkg-buildpackage would be a better place to say you don't
have all the needed deps, also I don't think that dpkg-source should in
anyway attempt to setup a buildroot.
Right now sbuild is about the best thing we have for all of this, I would
personally love to have it directly in dpkg-dev since it's pretty self
standing and would satisfy all of these issues. Anyway, most of the
majority of people that will be using Build-* deps, will be using sbuild
anyway (no matter what you put into dpkg-{source,buildpackage}, and yes,
I'm refering to the autobuilders). So why not give everyone else the same
tools that are used by the folks that brought on this added feature in the
first place, that way we also avoid duplication of effort.
Ben
Bug#40766: Rewrite of configuration files section
OK, almost there. But one quickie: The sentence: A package may not modify a conffile of another package. was replaced by something better, but I'm not sure what the conclusion was. How about: The maintainer scripts of a package may not modify a conffile of _any_ package, including the one the scripts belong to. as proposed by Hamish. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Bug#43724: experimental patch for very much faster dpkg -R
Previously Julian Gilbey wrote: It seems that this proposal was rejected due to dpkg -iGROEB being superceded by apt-cdrom. Is this correct? I don't think so.. this was that patch that added an option to dpkg to use filenames instead of looking inside packages, right? Wichert. Well, it talked about such a patch, yes. I'll leave it up to you ;) Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Source dependencies: are we ready?
Previously sparc porters wrote: Personally I don't think dpkg-source can enforce this. The name dpkg-source here is a bit if a misnomer; it is in fact the name of a package that includes new versions of dpkg-source, dpkg-buildpackage, dpkg-genchangers, etc. I have the tarball available for anyone who wants to play with it. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | pgprqeZ4gbx75.pgp Description: PGP signature
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 07:13:27PM +0200, Wichert Akkerman wrote: Previously sparc porters wrote: Personally I don't think dpkg-source can enforce this. The name dpkg-source here is a bit if a misnomer; it is in fact the name of a package that includes new versions of dpkg-source, dpkg-buildpackage, dpkg-genchangers, etc. I have the tarball available for anyone who wants to play with it. I still think sbuild is the way to go. Since it already handles local overrides, downloading/installing/removing packages needed to do the building as well as removing/installing packages that were shifted from the Build-* deps once the build is complete. On top of that, it can download the sources by specific version and distribution and it's already well tested and proven. Ben
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 07:13:27PM +0200, Wichert Akkerman wrote: The name dpkg-source here is a bit if a misnomer; it is in fact the name of a package that includes new versions of dpkg-source, dpkg-buildpackage, dpkg-genchangers, etc. I have the tarball available for anyone who wants to play with it. I would be interested in taking a look at it. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: Build-depends = change policy wording
Julian Gilbey [EMAIL PROTECTED] writes: Given that there are now two sorts of depends, I am changing the paragraph: Packages may not depend on packages with lower priority values. If this should happen, one of the priority values will have to be adapted. to read: Binary packages may not depend on binary packages with lower priority values. If this should happen, one of the priority values will have to be adapted. This is consistent with the changed wording in the packaging manual introduced by the accepted proposal introducing build-time dependencies. Are there any objections? Why change? Would it be OK for the source of mount to depend on ssh? (just a realy extreme example) Source packages should also not depend on other packages with higher priority, otherwise there could arise a situation where you can´t build a package because you can´t build another. Actually checking that all sources can be build is a fulltime job. There may not be any loops in the dependencies of sources (except for essential and required). May the Source be with you. Goswin
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 09:02:59PM +0200, Wichert Akkerman wrote: Previously sparc porters wrote: I still think sbuild is the way to go. I still think sbuild is not the way to go and would rather see sbuild modified to handle the new source format. Oh, in case someone hasn't noticed: this is the rumoured new source format from Klee Dienes. If you want to test it grab klee.tar.gz from ~wakkerma on master. You will need to have python installed btw. Sbuild calls dpkg-source to unpack, what does it have to do with the source format?! All it has to do is call whatever executable is needed for the unpacking. It _already_ handles _everything_ else, _and_ the Build Dependencies. My suggestion is to keep the enforcement of build deps out of raw tools like dpkg-source and dpkg-buildpackage and in specialized tools like sbuild (which already has it) and apt (which already builds and downloads packages, so it can handle checking build deps with modifications). Ben
Bug#44922: PROPOSAL] handling missing stuff in /usr/local
Julian Gilbey [EMAIL PROTECTED] writes: + However, because '/usr/local' and its contents are for + exclusive use of the local administrator, a package must + not rely on the presence or absence of files of ^ + directories in '/usr/local' for normal operation./p Do you mean 'or' there? Falk
Re: Build-depends = change policy wording
On Tue, 26 Oct 1999, Julian Gilbey wrote: Given that there are now two sorts of depends, I am changing the paragraph: Packages may not depend on packages with lower priority values. If this should happen, one of the priority values will have to be adapted. to read: Binary packages may not depend on binary packages with lower priority values. If this should happen, one of the priority values will have to be adapted. Mmm, is this change really needed? *Source* packages do not have priorities... How about: Packages may not depend on packages with lower priority values (excluding build-time dependencies). If this should happen, one of the priority values will have to be adapted. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Suggestion to and how to alow different compression for .debs
Goswin Brederlow wrote: Why not pipe it through uncompress.sh as and if present in the control.tar.gz? Why not change to using the shar archive format for our packages? Because it's overly complicated, and unnecessary. -- see shy jo
Bug#40934: PROPOSAL: changelog.html.gz sanitization
I second this proposal. [Joey, do you want to change the status of this proposal in the BTS?] Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Build-depends = change policy wording
Why change? Would it be OK for the source of mount to depend on ssh? (just a realy extreme example) No: ssh is not in main (it's in non-US/non-free at present, although it may well end up in non-US/main very soon). See policy 2.1.2 for the definition of the `main' section. Source packages should also not depend on other packages with higher priority, otherwise there could arise a situation where you can?t build a package because you can?t build another. No, I disagree. We've discussed this before. Many of the standard (even Essential) programs need development programs (auto*, gcc, debhelper, -dev packages etc.) in order to compile them. However, once we've got a full set of source dependencies we will be able to pinpoint such circular cases, though in practice they're probably mainly significant for porters only. Actually checking that all sources can be build is a fulltime job. There may not be any loops in the dependencies of sources (except for essential and required). Why not? There's a well-known procedure called bootstrapping Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Bug#44922: PROPOSAL] handling missing stuff in /usr/local
Julian Gilbey [EMAIL PROTECTED] writes: + However, because '/usr/local' and its contents are for + exclusive use of the local administrator, a package must + not rely on the presence or absence of files of ^ + directories in '/usr/local' for normal operation./p Do you mean 'or' there? Yes, thanks! Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Suggestion to and how to alow different compression for .debs
On 21 Oct 1999, Goswin Brederlow wrote: Of cause policy should encourage to use bzip2 (or gzip if smaller) and base packages must use tar.gz (or tar.bz2 if bzip2 is in base) so that one can update debian. Any package using a non default compression must predepend on that compressor, but that should be clear for the packaging scripts and maintainer. If there has to be a line added to control, why not instead make a new line such as Archive: tar.bz2 (with Archive: tar.gz assumed if not specified) and not worry about a custom how_to_unpack script? Granted, this method would only support predefined types but would be simpler, and there aren't _that_ many formats people are dying to use - tar.gz and tar.bz2 (and possibly tar.Z) could probably make 99.9% of everyone happy, and stuff like tar.zip, tar.arj, tar.lha etc could be added if anyone really wanted it. Chris Pimlott (IANADD)
Re: Build-depends = change policy wording
Julian Gilbey [EMAIL PROTECTED] writes: On Tue, 26 Oct 1999, Julian Gilbey wrote: Given that there are now two sorts of depends, I am changing the paragraph: Packages may not depend on packages with lower priority values. If this should happen, one of the priority values will have to be adapted. to read: Binary packages may not depend on binary packages with lower priority values. If this should happen, one of the priority values will have to be adapted. Mmm, is this change really needed? *Source* packages do not have priorities... How about: Packages may not depend on packages with lower priority values (excluding build-time dependencies). If this should happen, one of the priority values will have to be adapted. Why exclude source from that? I would suggest the same rule for source and I would also suggest that sources gain the (highest) priority from the packages they produce. Would there be any package violating the policy that way? May the Source be with you. Goswin
Re: Suggestion to and how to alow different compression for .debs
Chris Pimlott [EMAIL PROTECTED] writes: On 21 Oct 1999, Goswin Brederlow wrote: Of cause policy should encourage to use bzip2 (or gzip if smaller) and base packages must use tar.gz (or tar.bz2 if bzip2 is in base) so that one can update debian. Any package using a non default compression must predepend on that compressor, but that should be clear for the packaging scripts and maintainer. If there has to be a line added to control, why not instead make a new line such as Archive: tar.bz2 (with Archive: tar.gz assumed if not specified) and not worry about a custom how_to_unpack script? Granted, this method would only support predefined types but would be simpler, and there aren't _that_ many formats people are dying to use - tar.gz and tar.bz2 (and possibly tar.Z) could probably make 99.9% of everyone happy, and stuff like tar.zip, tar.arj, tar.lha etc could be added if anyone really wanted it. Chris Pimlott (IANADD) You would need a switch case statement that tests for all possible formats that might be allowed. Having an uncompress.sh the procedure will be identical for all compressors, just pipe it through it. Its far easier to replace the gzip call with an uncompress.sh call than to program a switch case into all scripts. May the Source be with you. Goswin
Re: Suggestion to and how to alow different compression for .debs
Joey Hess [EMAIL PROTECTED] writes: Goswin Brederlow wrote: Why not pipe it through uncompress.sh as and if present in the control.tar.gz? Why not change to using the shar archive format for our packages? Because it's overly complicated, and unnecessary. Whats complicated about using uncompress.sh instead of gzip and fallback to gzip if not present? The gain would be bzip2 compression, which is needed to reduce the size of debian and also any other compressor that might become commonly used or be extremly good at some sort of data. Don´t tell me that saving 3-4 GB of mirror space is unnecessary. May the Source be with you. Goswin
Re: Source dependencies: are we ready?
On Tue, Oct 26, 1999 at 03:46:23PM -0400, Ben Collins wrote: Sbuild calls dpkg-source to unpack, what does it have to do with the source format?! All it has to do is call whatever executable is needed for the unpacking. It _already_ handles _everything_ else, _and_ the Build Dependencies. My suggestion is to keep the enforcement of build deps out of raw tools like dpkg-source and dpkg-buildpackage and in specialized tools like sbuild (which already has it) and apt (which already builds and downloads packages, so it can handle checking build deps with modifications). I agree with Ben that dpkg-source should not care about build dependencies (hey, it only unpacks the source, I only need ar and tar and gzip for this!) dpkg-buildpackage should optionally verify the build dependencies only. apt should have an option to fulfill source depends for a set of packages. sbuild is overkill for most people. Also, it is tightly related to the wanna build autobuilder. It is pretty much hackish, and I would rather see something replacing sbuild than vice versa. All IMNSHO. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Build-depends = change policy wording
On Tue, Oct 26, 1999 at 07:28:31PM +0200, Goswin Brederlow wrote: Source packages should also not depend on other packages with higher priority, otherwise there could arise a situation where you can´t build a package because you can´t build another. This is not useful. Priority rating for source packages is not useful at all. Actually checking that all sources can be build is a fulltime job. There may not be any loops in the dependencies of sources (except for essential and required). Again this is wrong. Circular build time dependencies are annoying but common. I am all for making it easier to bootstrap Debian, but let's first add source deps, and after a year, we can analyze the data with graph theory. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Suggestion to and how to alow different compression for .debs
Goswin Brederlow wrote: Whats complicated about using uncompress.sh instead of gzip and fallback to gzip if not present? Tons of things. What about programs called in uncompress.sh -- are dependancies supposed to be fullfilled then? What happens when the script fails? What if you don't trust debian, but want to unpack a debian package anyway, without running any scripts from it? What about speed? The gain would be bzip2 compression BenC has already implemented this, from what I hear. -- see shy jo
Re: Build-depends = change policy wording
Julian Gilbey [EMAIL PROTECTED] writes: Why change? Would it be OK for the source of mount to depend on ssh? (just a realy extreme example) No: ssh is not in main (it's in non-US/non-free at present, although it may well end up in non-US/main very soon). See policy 2.1.2 for the definition of the `main' section. Source packages should also not depend on other packages with higher priority, otherwise there could arise a situation where you can´t build a package because you can´t build another. No, I disagree. We've discussed this before. Many of the standard (even Essential) programs need development programs (auto*, gcc, debhelper, -dev packages etc.) in order to compile them. I see your point there. Any developement tool would have to be priority essential to fullfill the policy. And just saying that standard sources may not depends on optional packages doesn´t realy make sense. We would need a complete new set of priorities for sources. Something like mount's source isn´t essential to compile anything, but gcc would be essential, same with debhelper. However, once we've got a full set of source dependencies we will be able to pinpoint such circular cases, though in practice they're probably mainly significant for porters only. Actually checking that all sources can be build is a fulltime job. There may not be any loops in the dependencies of sources (except for essential and required). Why not? There's a well-known procedure called bootstrapping The first thing is bootstrapping. You should be able to easily see whats needed for bootstrapping, i.e. what source is essential. gcc would fall under that section, but not fsck. In other words essential are all the sources that you need to have compiled somehow before you can start using the debian sources. Another thing are loops in general. If two packages need each other it might become impossible for an autobuild demon to build them correctly. As an example consider the case where a new libc is introduced and all must be compiled for that lib. The autobuild demons would use still not recompiled binaries/libs to build the new packages and link them against that and then you have packages depending on two conflicting libcs. Having priorities for sources would capsulate sets of packages. Another aspect of source priorities would be that autobuild demons could build sources with higher priority first. May the SOurce be with you. Goswin PS: Since sources don´t have priorities at the moment they can´t violate he current wording of policy, so why change it?
Bug#43928: libc and kernel source policy
On Tue, Oct 26, 1999 at 10:21:21AM -0400, Ben Collins wrote: is actually nothing wrong with this policy. Personally, I would hope that it always stays this way. Ditto. For the non-i386 archs, it makes for much less bug reports, and more stable/consistent builds. FWIW, stability and consistency are the primary reasons I started the current convention a few years ago and those reasons are still valid today. Perhaps the real argument should be, to have something that allows the users to specify their own headers without libc-dev overwriting them. There is -- it's called gcc -I. David -- David Engel [EMAIL PROTECTED]
