[PROPOSED] Change package relations policy to remove references to non-free from main
Package: debian-policy I assume we are all aware of the discussion a couple of months ago about removing references to non-free from main. There was a consensus this should be done and a consensus was formed to do this via a new Enhances relation for packages. Enhances works in the opposite direction from Suggests: it allows a package a to state that it can enhance the functionality of a package b. So instead of package b declaring a Suggests on package a we now make package a Enhance package b. Using this we can remove all Suggests from packages in main to packages outside of main by replacing them with an Enhances-declaration in the non-main package. Detailed listing of changes needed in the policy manual: 2.1.2 The main section Replace the first item with: * must not have a relation with or need a package outside of main. (thus, the package may not declare a Depends, Recommends, Suggests or other normal or build-time relationship on a non-main package), Detailed listing of changes needed in the packaging manual: 8.2 Binary Dependencies Add `Enhances' to the title of the section Add the following to the list of relations: `Enhances' This field is similar to Suggests but works in the opposite direction. It is used to declare that a package can enhance the functionality of another package. `dselect' will offer a list of packages that enhance a package if the enhanced package is selected for installation. 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 | pgpDOydDGVlBW.pgp Description: PGP signature
Re: [PROPOSED] Change package relations policy to remove references to non-free from main
On Mon, Nov 29, 1999 at 12:39:46AM +0100, Wichert Akkerman wrote: I assume we are all aware of the discussion a couple of months ago about removing references to non-free from main. There was a consensus this should be done and a consensus was formed to do this via a new Enhances relation for packages. Enhances works in the opposite direction from Suggests: it allows a package a to state that it can enhance the functionality of a package b. So instead of package b declaring a Suggests on package a we now make package a Enhance package b. Using this we can remove all Suggests from packages in main to packages outside of main by replacing them with an Enhances-declaration in the non-main package. I will conditionally support this... My first condition is that this is phased in--it must not be a requirement for potato or even potato+1. (I'll accept potato alone if a reasonable consensus of people believe we can do it for potato+1 without interfering with release timeframes..) My second condition is that this is done as part of the ftp archive revamp rather than before or after. If Guy is going to implement pools for potato+1 it doesn't make sense to make a bunch of changes that include significant modifications to dselect twice. ie, if packages are going to start using Enhances, they should start using Keywords at the same time. This (hopefully) prevents duplicated work and wasted bandwidth. I realize both of these are implementation issues, however the /usr/doc fiasco has shown that anything not documenting current practice that isn't backwards-compatible needs implementation issues discussed beforehand. The reasonable condition that bandwidth not be wasted by modifying every (or at least most) packages twice I think is just a practicality concern. It's also a convenient excuse to make sure this is done at the same time package pools are so moving of non-free and contrib to help seperate them from main can happen at the same time.. Hopefully this will make sure people trying to do all of those things cooperate and things happen smoothly. -- - Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43 - [EMAIL PROTECTED] 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 -- james but, then I used an Atari, I was more likely to win the lottery in ten countries simultaneously than get accelerated X pgpC1cMQ6Ozim.pgp Description: PGP signature
Bug#51472: packaging manual shouldn't dictate dselect behaviour
Package: packaging-manual The current packaging-manual dictates how dselect reacts to relations from packages. If you look at section 8.2 there are statements such as: `Recommends' [...] It is treated by `dselect' exactly as `Depends' is; this makes it hard for the user to select things so as to leave `Recommends' fields unsatisfied, but they are able to do so by being persistent. Similar statements are made for other relations. I don't think the packaging-manual should dictate how dselect handles relations. The current CVS version of dselect already changed its behaviour somewhat making some of these statements false. 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 | pgpFng5oGTgeT.pgp Description: PGP signature
Bug#50502: marked as done (Packaging manual typo /var/lib/dpkg/*.shlibs)
Your message dated Mon, 29 Nov 1999 00:38:58 + with message-id [EMAIL PROTECTED] and subject line Closed in debian-policy/packaging-manual 3.1.1.1 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; 11 Nov 1999 21:47:16 + Received: (qmail 22972 invoked from network); 11 Nov 1999 21:47:14 - Received: from vasquez.zip.com.au (203.12.97.41) by master.debian.org with SMTP; 11 Nov 1999 21:47:14 - Received: from localhost (banana46.zip.com.au [61.8.30.78]) by vasquez.zip.com.au (8.9.2/8.9.1) with ESMTP id IAA03156 for [EMAIL PROTECTED]; Fri, 12 Nov 1999 08:47:06 +1100 (EST) Received: from gg by localhost with local (Exim 2.05 #1 (Debian)) id 11m2L5-0001gP-00; Fri, 12 Nov 1999 08:05:07 +1000 To: [EMAIL PROTECTED] Subject: Packaging manual typo /var/lib/dpkg/*.shlibs From: Kevin Ryde [EMAIL PROTECTED] Date: 12 Nov 1999 08:05:07 +1000 Message-ID: [EMAIL PROTECTED] Lines: 17 User-Agent: Gnus/5.070099 (Pterodactyl Gnus v0.99) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Package: packaging-manual Version: 3.1.0.0 Severity: wishlist In the How to write debian/shlibs.local section: --- packaging.sgml.old Fri Nov 12 07:56:53 1999 +++ packaging.sgml Fri Nov 12 07:57:51 1999 @@ -4742,7 +4742,7 @@ p This file is intended only as a emtemporary/em fix if your binaries depend on a library which doesn't provide - its own tt/var/lib/dpkg/*.shlibs/tt file yet. + its own tt/var/lib/dpkg/info/*.shlibs/tt file yet. /p p --- Received: (at 50502-done) by bugs.debian.org; 29 Nov 1999 01:04:27 + Received: (qmail 16267 invoked from network); 29 Nov 1999 01:04:27 - Received: from mserv1c.u-net.net (195.102.240.33) by master.debian.org with SMTP; 29 Nov 1999 01:04:27 - Received: from [195.102.196.26] (helo=polya) by mserv1c.u-net.net with esmtp (Exim 2.10 #35) id 11sFDe-0006LM-00; Mon, 29 Nov 1999 01:03:06 + Received: from jdg by polya with local (Exim 3.03 #1 (Debian)) id 11sEqI-0005Na-00; Mon, 29 Nov 1999 00:38:58 + Date: Mon, 29 Nov 1999 00:38:58 + From: Julian Gilbey [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Closed in debian-policy/packaging-manual 3.1.1.1 Message-ID: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0i These have been closed by debian-policy version 3.1.1.1, now uploaded. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Bug#50857: marked as done (Packaging-manual has typos.)
Your message dated Mon, 29 Nov 1999 00:38:58 + with message-id [EMAIL PROTECTED] and subject line Closed in debian-policy/packaging-manual 3.1.1.1 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 Nov 1999 14:25:46 + Received: (qmail 22069 invoked from network); 21 Nov 1999 14:25:45 - Received: from pop3.tky.3web.ne.jp ([EMAIL PROTECTED]) by master.debian.org with SMTP; 21 Nov 1999 14:25:45 - Received: from debian ([EMAIL PROTECTED] [202.235.214.44]) by pop3.tky.3web.ne.jp (8.9.3+3.2W/POP3.TKY) with ESMTP id XAA15285 for [EMAIL PROTECTED]; Sun, 21 Nov 1999 23:25:38 +0900 (JST) Received: from debian (debian.localhost) [127.0.0.1] (hayase) by debian with esmtp (Exim 2.05 #1 (Debian)) id 11pXwj-0003ve-00; Sun, 21 Nov 1999 23:26:29 +0900 Date: Sun, 21 Nov 1999 23:26:29 +0900 Message-ID: [EMAIL PROTECTED] From: HAYASE Shigenori [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Packaging-manual has typos. User-Agent: Wanderlust/1.0.3 (Notorious) SEMI/1.12.1 ([JR] Nonoichi) FLIM/1.12.7 (=?ISO-8859-4?Q?Y=FEzaki?=) Emacs/20.3 (i386-debian-linux-gnu) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.12.1 - [JR] Nonoichi) Content-Type: text/plain; charset=US-ASCII Package: packaging-manual Version: 3.1.1.0 Packaging manual has two typos. 1196c1196 qref id=relationshipsttBuild-Depends/tt at --- qref id=relationshipsttBuild-Depends/tt et 3571c3571 p --- /p -- HAYASE Shigenori ([EMAIL PROTECTED]) --- Received: (at 50857-done) by bugs.debian.org; 29 Nov 1999 01:04:27 + Received: (qmail 16267 invoked from network); 29 Nov 1999 01:04:27 - Received: from mserv1c.u-net.net (195.102.240.33) by master.debian.org with SMTP; 29 Nov 1999 01:04:27 - Received: from [195.102.196.26] (helo=polya) by mserv1c.u-net.net with esmtp (Exim 2.10 #35) id 11sFDe-0006LM-00; Mon, 29 Nov 1999 01:03:06 + Received: from jdg by polya with local (Exim 3.03 #1 (Debian)) id 11sEqI-0005Na-00; Mon, 29 Nov 1999 00:38:58 + Date: Mon, 29 Nov 1999 00:38:58 + From: Julian Gilbey [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Closed in debian-policy/packaging-manual 3.1.1.1 Message-ID: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0i These have been closed by debian-policy version 3.1.1.1, now uploaded. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Bug#50617: imp blows away hand-edited changes...
this avoids the need to choose between debconf and hand-edited configuration (which is not a solution at all) - the sysadmin can modify the template however they like and their changes will remain after the next time the real config file is generated...and values will still be pulled out of debconf to 'fill in the blanks'. (it's usually a good idea to insert comments at the top of the generated file warning DO NOT EDIT and refer to the template file instead. also include brief instructions on how to generate the real conf from the template, or provide a Makefile or script which does it automatically) also..I forgot to put this piece into the generated files...will do this in the next release as well. Ivan -- Ivan E. Moore II [EMAIL PROTECTED] http://snowcrash.tdyc.com GPG KeyID=90BCE0DD GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD
Bug#51262: Suggestion: Packages should carry a manpage
[EMAIL PROTECTED] (Brian Mays) writes: Policy says that any binary must come with a manpage. I would like to have the same for packages. For every package? You must be kidding!! I just looked for a parser generator that outputs C++ code and found pccts. After installation I tried man pccts, but that failed. /usr/doc/pccts doesn't contain examples, so how do I use the thing? pccts in fact contains several binaries, but non is called pccts. The main binary is called antlr and has a good manpage. My suggestion is now, that man pccts should either point to the main binaries manpage or show a page that gives a one-line description of the binaries of the package or one that has just relevant see also: xxx entries. What do you think? While I agree that it is probably a good idea for large packages, with many binaries, to provide such a man page (in section 7, of course), it makes no sense for packages in general. Personally, I think that such policy would be a waste of our developers' time to write these pages and a waste of disk space to store them. In the case of most packages the main binary will be named just like the package, like bash, zsh, gcc,... Of cause I don´t want another manpage for the gcc package, the one for gcc is enough. It should be rare that a package doesn´t contain a binary thats called after the package and only for those a seperate manpage or a link to the main programs manpage should be provided. May the Source be with you. Goswin
Re: [PROPOSED] Change package relations policy to remove references to non-free from main
Wichert Akkerman [EMAIL PROTECTED] writes: I assume we are all aware of the discussion a couple of months ago about removing references to non-free from main. There was a consensus this should be done and a consensus was formed to do this via a new Enhances relation for packages. That's not what I remember; I don't remember us ever *reaching* a concensus. Esp. since I was part of that discussion, and *I* never agreed that that was the best approach! IIRC, RMS suggested it, and IWJ said he could implement it, but that was all at the very beginning of the discussion, long before we had anything resembling consensus. The problem with the Enhances idea (which several people, including me, mentioned at the time) is that it puts the responsibility on the wrong package. If, e.g, my package can take advantage of Netscape, then it should be the responsibility of my package, not Netscape, to mention that fact. Otherwise, Netscape (in particular) may need to have hundreds of packages listed under Enhances. Not to mention that fact that it may require new uploads of Netscape simply to add or remove packages from Netscape's Enhances field. That's simply not a good or sensible design. It may be ok for gimp-nonfree or tetex-nonfree, where the Enhances is for one-and-only-one package, but it doesn't work for the great majority of cases. I still think that a field like Will-take-advantage-of is a better approach, i.e. a quieter version of Suggests, which is invisible when the suggested package isn't available. (Better names for this field are welcomed.) I could and would use a Will-take-advantage-of field. But I'm *NOT* going to bother to try to get Festival's maintainer or Netscape's maintainer to add an Enhances field for my package. That's just too much hassle. I'd rather do what I'm doing now: mention the non-free packages in the documentation, but not in any fields that dselect/apt can see. I'm not opposed to the idea of Enhances, but I don't think it solves the problem it's intended to solve. I wouldn't mind if it existed *alongside* of a Will-take-advantage-of field, but I think it would be a bit redundant in that case. The Enhances idea is a bit too much like expecting a library to list all the packages that use it. It just doesn't make sense. Package: Netscape Version: whatever Depends: blah-de-blah Enhances: fvwm, icewm, enlightenment, sawmill, xchat, xchat-gnome, gnome-panel, gnome-terminal, emacs19, emacs20, xemacs19, xemacs20, xemacs21, gxedit, gmc, gimp, etc., etc., etc. :-) Note, that's just a small sampling of the programs which don't suggest Netscape, but which *DO* try to use it, often whether it's available or not (as I discovered when I uninstalled Netscape for while). All of these programs would (or should) be suggesting Netscape if Netscape were free. Enhances is a bad design. If it's the best we can do, then I feel sorry for us. :-) cheers -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Bug#51412: conflict in documents
On Sun, Nov 28, 1999 at 12:01:44AM -0700, Bdale Garbee wrote: There needs to be a canonical list of the packages that are part of the build-essential set *somewhere*. Why? The point of the current way is to reduce the risk of having an outdated authoritative list of build-essential packages. *And* it makes it possible for us to update the list without going through the policy amendment procedure every time something changes in the build setup. It is my intention to keep the list as accurate as I can, but I don't like to mention specific packages in policy. That's another reason why build-essential is not authoritative. This all was discussed when the build-time dependency spec was being hammered out on -policy. The fact that the policy is vague It is not vague. The definition is (or at least attempts to be) unambiguous. It takes a little effort to find out what the set actually is, but presumably you cannot arrive in two different sets based on that definition. The build-essential package is there to provide you a precalcualated set. However, if I made a mistake in determining the set, the mistake is not automatically part of policy. This is yet another point for the current arrangement. and the list in your package carries a wimp-out disclaimer in combination fails to meet this need. I rephrased the disclaimer a little for build-essential 2, which is in Incoming. Is it satisfactory now? If not, can you suggest a better wording? It seems that what you are really saying is that this is another bug in the policy. No, I am saying that the arrangement is like this by design, not by accident. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Bug#51262: Suggestion: Packages should carry a manpage
I (Brian Mays) wrote: While I agree that it is probably a good idea for large packages, with many binaries, to provide such a man page (in section 7, of course), it makes no sense for packages in general. Personally, I think that such policy would be a waste of our developers' time to write these pages and a waste of disk space to store them. Goswin Brederlow added: In the case of most packages the main binary will be named just like the package, like bash, zsh, gcc,... Of cause I don´t want another manpage for the gcc package, the one for gcc is enough. It should be rare that a package doesn´t contain a binary thats called after the package and only for those a separate manpage or a link to the main programs manpage should be provided. [ Here I assume that you are referring to packages that actually *contain* a binary. I can think of MANY examples of packages that contain no binaries at all. ] The example that you cite is rather poor. You complain that the pccts package does not contain a pccts man page, but did you even bother to read the package's description? The description clearly lists the main tools (binaries) contained in the package. Why wasn't that sufficient? What I'm trying to avoid is wasting my time writing a silly man page listing two binaries contained in a small package (e.g., netcdf-bin) that are already described in the package's description field. Brian
Re: [PROPOSED] Change package relations policy to remove references to non-free from main
Wichert Akkerman [EMAIL PROTECTED] writes: I assume we are all aware of the discussion a couple of months ago about removing references to non-free from main. There was a consensus this should be done and a consensus was formed to do this via a new Enhances relation for packages. On Tue, Nov 30, 1999 at 04:40:14AM -0800, Chris Waters wrote: That's not what I remember; I don't remember us ever *reaching* a concensus. Esp. since I was part of that discussion, and *I* never agreed that that was the best approach! IIRC, RMS suggested it, and IWJ said he could implement it, but that was all at the very beginning of the discussion, long before we had anything resembling consensus. As I recall, the discussion kind of died out when people realized that this would require a dpkg change -- at the time, dpkg change seemed to imply that several years might go by before the feature became available. If, e.g, my package can take advantage of Netscape, then it should be the responsibility of my package, not Netscape, to mention that fact. Otherwise, Netscape (in particular) may need to have hundreds of packages listed under Enhances. Not to mention that fact that it may require new uploads of Netscape simply to add or remove packages from Netscape's Enhances field. That's simply not a good or sensible design. It may be ok for gimp-nonfree or tetex-nonfree, where the Enhances is for one-and-only-one package, but it doesn't work for the great majority of cases. That's solvable: create a virtual package which has a free instance (such as Mozilla) which provides the interface you're taking advantage of. -- Raul
Bug#51262: Info received (was Bug#51262: Suggestion: Packages should carry a manpage )
Thank you for the additional information you have supplied regarding this problem report. It has been forwarded to the developer(s) and to the developers mailing list to accompany the original report. Your message has been sent to the package maintainer(s): Debian Policy List debian-policy@lists.debian.org If you wish to continue to submit further information on your problem, please send it to [EMAIL PROTECTED], as before. Please do not reply to the address at the top of this message, unless you wish to report a problem with the Bug-tracking system. Darren Benham (administrator, Debian Bugs database)
Re: [PROPOSED] Change package relations policy to remove references to non-free from main
On Sun, Nov 28, 1999 at 10:14:29PM -0800, Joseph Carter wrote: I will conditionally support this... My first condition is that this is phased in--it must not be a requirement for potato or even potato+1. (I'll accept potato alone if a reasonable consensus of people believe we can do it for potato+1 without interfering with release timeframes..) I agree that we shouldn't require it for potato. I agree that non-compliance with this policy probably won't be release critical. On the other hand, I find it hard to imagine any circumstance that would prevent fixing the small set of packages which would be affected by this policy by potato+1. My second condition is that this is done as part of the ftp archive revamp rather than before or after. If Guy is going to implement pools for potato+1 it doesn't make sense to make a bunch of changes that include significant modifications to dselect twice. ie, if packages are going to start using Enhances, they should start using Keywords at the same time. This (hopefully) prevents duplicated work and wasted bandwidth. I think what you're saying here is: the policy which supports Enhances: should be the same as the policy which supports Keywords: ? [Because it would be silly, in this case, to postpone package updates till after some proposed ftp site administration gets done.] The reasonable condition that bandwidth not be wasted by modifying every (or at least most) packages twice I think is just a practicality concern. It's also a convenient excuse to make sure this is done at the same time package pools are so moving of non-free and contrib to help seperate them from main can happen at the same time.. Hopefully this will make sure people trying to do all of those things cooperate and things happen smoothly. Sure, but this concern applies to most policy updates, not just the two you mentioned. More generally, we need some kind of release management for debian-policy and that should somehow interelate to general debian release management. This a rather larger topic, in general, but hopefully we can just rely on the policy editors for now. -- Raul
Bug#51262: Suggestion: Packages should carry a manpage
On Sun, Nov 28, 1999 at 07:16:19PM +0100, Goswin Brederlow wrote: [EMAIL PROTECTED] (Brian Mays) writes: Policy says that any binary must come with a manpage. I would like to have the same for packages. For every package? You must be kidding!! I just looked for a parser generator that outputs C++ code and found pccts. After installation I tried man pccts, but that failed. /usr/doc/pccts doesn't contain examples, so how do I use the thing? pccts in fact contains several binaries, but non is called pccts. The main binary is called antlr and has a good manpage. My suggestion is now, that man pccts should either point to the main binaries manpage or show a page that gives a one-line description of the binaries of the package or one that has just relevant see also: xxx entries. What do you think? While I agree that it is probably a good idea for large packages, with many binaries, to provide such a man page (in section 7, of course), it makes no sense for packages in general. Personally, I think that such policy would be a waste of our developers' time to write these pages and a waste of disk space to store them. In the case of most packages the main binary will be named just like the package, like bash, zsh, gcc,... Of cause I don´t want another manpage for the gcc package, the one for gcc is enough. It should be rare that a package doesn´t contain a binary thats called after the package and only for those a seperate manpage or a link to the main programs manpage should be provided. What about docs ? What about themes ? Do you want them to contain manpage ?
Bug#51412: conflict in documents
On Sun, Nov 28, 1999 at 12:01:44AM -0700, Bdale Garbee wrote: There needs to be a canonical list of the packages that are part of the build-essential set *somewhere*. Why? Ok, I've gone back and re-read the policy section carefully, and thought about this quite a bit. Fundamentally, I'm unhappy with the definition of build-essential. I think it should have tried to define the set of packages that will allow packages typical of the majority of Debian packages to be built, instead of having a goal as simple as compiling a hello world in C/C++. That is the kind of definition I was expecting, and it's why I was so surprised to find that debhelper wasn't considered essential. I pondered for a bit whether I might have been happier if there was no build-essentials list at all, and the list had to be complete. The notion was that if something like 70% of current packages (the last estimate I saw of debhelper adoption) are going to need to specify explicit dependencies to comply with current policy, why we didn't just go ahead and make all packages be explicit about all of their build dependencies. Some optimization of the list size (which is all the current build-essential really does) in each package is better than nothing, though. I rephrased the disclaimer a little for build-essential 2, which is in Incoming. Is it satisfactory now? If not, can you suggest a better wording? Yes, it is better. Thanks. The attempt to define what is essential without specifying a list of packages is understandable, and probably appropriate. However, the reality is that bugs are going to be filed against any package that doesn't explicitly note dependencies on anything that isn't on the list. I already have at least one such regarding debhelper. So, for all intents and purposes, the list *is* a manifestation of policy, no matter how much it tries to claim otherwise. Such is life. I'm sure you'll do what you can to keep it current and accurate, and that's good enough. I am saying that the arrangement is like this by design, not by accident. I'm not entirely happy with that, but I'll live with it. Thanks for taking the time to engage in this discussion. I know how annoying it is to have things like this come up *after* you think an issue is settled. Bdale
Re: [PROPOSED] Change package relations policy to remove references to non-free from main
Previously Raul Miller wrote: As I recall, the discussion kind of died out when people realized that this would require a dpkg change -- at the time, dpkg change seemed to imply that several years might go by before the feature became available. Well, the times they are a'changing. Part of the needed chances have already been made, and I hope to have everything working at the end of the week. 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 | pgpP8Eg0r4SeT.pgp Description: PGP signature
Re: [PROPOSED] Change package relations policy to remove references to non-free from main
Previously Raul Miller wrote: I agree that we shouldn't require it for potato. However if the amount of work is reasonably small I wouldn't mind personally submiting patches for packages or NMU'ing a couple if needed. If this is done it means the FSF might start distributing Debian as well, which I really want to see 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 | pgpQVj49G2fNz.pgp Description: PGP signature
Re: [PROPOSED] Change package relations policy to remove references to non-free from main
Previously Chris Waters wrote: The problem with the Enhances idea (which several people, including me, mentioned at the time) is that it puts the responsibility on the wrong package. Yes and no. It's actually a nice addition to the current sent of relations since we had no way for this kind of reverse relation. It's true that for some of the existing relations replacing Suggests with Recommends puts the responsibility on the wrong package. However a reverse relation is the only way to completely remove references to non-main packages from main, which is what this proposal is all about. It's not all about design, there is a political message here as well. We want to be able to have a completely free system and be able to say here, you can use this and you'll be happy. You don't need anything that's not free at all. If we put weaken Suggest or create a new weaker version of it we don't do that since we still tell people that there are non-free packages that can improve things. 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 | pgpyIs3amvFux.pgp Description: PGP signature
Re: [PROPOSED] Change package relations policy to remove references to non-free from main
Previously Joseph Carter wrote: My first condition is that this is phased in--it must not be a requirement for potato or even potato+1. (I'll accept potato alone if a reasonable consensus of people believe we can do it for potato+1 without interfering with release timeframes..) I'm looking into how much work it is, from what I see so far it's actually not that much work. My second condition is that this is done as part of the ftp archive revamp rather than before or after. If Guy is going to implement pools for potato+1 it doesn't make sense to make a bunch of changes that include significant modifications to dselect twice. Please let me worry about dselect. This should be implemented at the end of this week, thanks to GNU who is putting one of their staff hackers on this. ie, if packages are going to start using Enhances, they should start using Keywords at the same time. This (hopefully) prevents duplicated work and wasted bandwidth. I'm thinking of adding a limit-command to dselect like mutt has. It seems pretty doable I'm not promising anything soon. I realize both of these are implementation issues, however the /usr/doc fiasco has shown that anything not documenting current practice that isn't backwards-compatible needs implementation issues discussed beforehand. The /usr/doc issue was a) blown all out of proportion and b) affected all packages. Comparing that to this doesn't make much sense. You seem to think that this needs a change in the archive and mention it being related to that a couple of times. Please realize that is not true at all. It means a few changes to a handful of packages and some coding work on dpkg and dselect. 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 | pgpJca5gFGxKb.pgp Description: PGP signature
Re: [PROPOSED] Change package relations policy to remove references to non-free from main
On Mon, Nov 29, 1999 at 10:06:39PM +0100, Wichert Akkerman wrote: need anything that's not free at all. If we put weaken Suggest or create a new weaker version of it we don't do that since we still tell people that there are non-free packages that can improve things. But sadly, on occasion, this is the case. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: [PROPOSED] Change package relations policy to remove references to non-free from main
On Mon, 29 Nov 1999, Wichert Akkerman wrote: Enhances works in the opposite direction from Suggests: it allows a package a to state that it can enhance the functionality of a package b. So instead of package b declaring a Suggests on package a we now make package a Enhance package b. Are you sure, that this works in the practice? I just looked at my packages and see, that transfig suggests netpbm-nonfree (it is needed to create GIF images with transfig). Your proposal means, that I should remove netpbm-nonfree from transfig's suggests and add Enhances: netpbm-nonfree to netpbm-nonfree. Is this really the correct way? Why does the maintainer of netpbm-nonfree have to change his package every time some package from main suggests it? This may be political correct, but it is not logical or consistent. Using this we can remove all Suggests from packages in main to packages outside of main by replacing them with an Enhances-declaration in the non-main package. That's the theory. The practice may be, that it will take a long time until the opposite package implements the Enhances header. Another disadvantage of this idea: It only works with a patched dselect, but if I (as a human) want to quickly see, which packages are needed (by doing a dpkg --print-available foo), I don't have a chance to find out, what packages are suggested. Instead of this, I always have to look at the non-free package list (or let some program do this), which packages enhance the package foo. I'm not sure, whether this is really a step forward. Ciao Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * pgpshGZfsUgz6.pgp Description: PGP signature
Re: [PROPOSED] Change package relations policy to remove references to non-free from main
On Mon, Nov 29, 1999 at 10:06:39PM +0100, Wichert Akkerman wrote: need anything that's not free at all. If we put weaken Suggest or create a new weaker version of it we don't do that since we still tell people that there are non-free packages that can improve things. On Mon, Nov 29, 1999 at 10:39:03PM +, Julian Gilbey wrote: But sadly, on occasion, this is the case. Hmm.. Go over to debian-legal and read the Corel threads there, then come back and tell me that everyone is happy, in general, about debian distributions which mix free and non-free software. And note that with Enhances: we still tell people that there are non-free packages that can improve things -- but the set of non-free packages is configurable, and not wedded to Debian. More generally, please don't mistake the current contents of non-free with future debian distributions: In my opinion, switching from Suggests: non-free-package to the reverse non-free Enhances: free package is very important for debian. We have a small collection of non-free software, but it's very likely that other organizations will build on our free software base and supply their own set of non-free software. Designing our system so that they can coexist with us is going to mean less silly forking of package instances, and that's a good thing, I think. -- Raul
Re: [PROPOSED] Change package relations policy to remove references to non-free from main
On Mon, Nov 29, 1999 at 08:54:56PM +0100, Roland Rosenfeld wrote: Your proposal means, that I should remove netpbm-nonfree from transfig's suggests and add Enhances: netpbm-nonfree to netpbm-nonfree. Is this really the correct way? Why does the maintainer of netpbm-nonfree have to change his package every time some package from main suggests it? This may be political correct, but it is not logical or consistent. Wichert just this week made the change to dpkg which to support this system. -- Raul
Re: [PROPOSED] Change package relations policy to remove references to non-free from main
On Mon, Nov 29, 1999 at 06:30:43PM -0500, Raul Miller wrote: On Mon, Nov 29, 1999 at 10:06:39PM +0100, Wichert Akkerman wrote: need anything that's not free at all. If we put weaken Suggest or create a new weaker version of it we don't do that since we still tell people that there are non-free packages that can improve things. On Mon, Nov 29, 1999 at 10:39:03PM +, Julian Gilbey wrote: But sadly, on occasion, this is the case. Hmm.. Go over to debian-legal and read the Corel threads there, then come back and tell me that everyone is happy, in general, about debian distributions which mix free and non-free software. [...] No, I'm not saying that I'm happy about it. I'm just commenting on the fact that there are non-free packages that can improve things. The fact that there may be no free package which can do the same is sad. Where does non-US fit into this, BTW? Can we suggest stuff in non-US/main from stuff in main under this proposal? Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
