Bug#514919: Removing support for uploads to multiple distributions
Hi, On Sat, Jun 20 2009, Russ Allbery wrote: diff --git a/policy.sgml b/policy.sgml index 43cf4d6..528c4b9 100644 --- a/policy.sgml +++ b/policy.sgml @@ -3118,76 +3118,39 @@ Package: libc6 distribution(s) where this version of the package should be installed. Valid distributions are determined by the archive maintainers.footnote - Current distribution names are: + Example distribution names in the Debian archive used in + file.changes/file files are: taglist compact=compact - tagemstable/em/tag - item - This is the current released version of Debian - GNU/Linux. Once the distribution is - emstable/em only security fixes and other - major bug fixes are allowed. When changes are - made to this distribution, the release number is - increased (for example: 2.2r1 becomes 2.2r2 then - 2.2r3, etc). - /item - tagemunstable/em/tag item - This distribution value refers to the - emdevelopmental/em part of the Debian - distribution tree. New packages, new upstream - versions of packages and bug fixes go into the - emunstable/em directory tree. Download from - this distribution at your own risk. - /item - - tagemtesting/em/tag - item - This distribution value refers to the - emtesting/em part of the Debian distribution - tree. It receives its packages from the - unstable distribution after a short time lag to - ensure that there are no major issues with the - unstable packages. It is less prone to breakage - than unstable, but still risky. It is not - possible to upload packages directly to - emtesting/em. - /item - - tagemfrozen/em/tag - item - From time to time, the emtesting/em - distribution enters a state of code-freeze in - anticipation of release as a emstable/em - version. During this period of testing only - fixes for existing or newly-discovered bugs will - be allowed. The exact details of this stage are - determined by the Release Manager. + This distribution value refers to the + emdevelopmental/em part of the Debian distribution + tree. Most new packages, new upstream versions of + packages and bug fixes go into the emunstable/em + directory tree. /item tagemexperimental/em/tag item - The packages with this distribution value are - deemed by their maintainers to be high - risk. Oftentimes they represent early beta or - developmental packages from various sources that - the maintainers want people to try, but are not - ready to be a part of the other parts of the - Debian distribution tree. Download at your own - risk. + The packages with this distribution value are deemed + by their maintainers to be high risk. Oftentimes they + represent early beta or developmental packages from + various sources that the maintainers want people to + try, but are not ready to be a part of the other parts + of the Debian distribution tree. /item /taglist p - You should list emall/em distributions that the - package should be installed into. - /p - - p - More information is available in the Debian Developer's - Reference, section The Debian archive. + Others are used for updating stable releases or for + security uploads. More information is available in the + Debian Developer's Reference, section The Debian + archive. /p /footnote + The Debian archive software only supports listing a single + distribution. Migration of packages to other distributions is + handled outside of the upload process. /p /sect1 Seconded. manoj -- I may be getting older, but I refuse to grow up! Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/
Bug#514919: Removing support for uploads to multiple distributions
On Fri, 19 Jun 2009, Russ Allbery wrote: Here is an updated patch for stating that the Debian archive doesn't support listing multiple distributions in the *.changes file. This reduces the footnote of distributions to just a couple of examples and defers to the devref for everything else. If this looks like the right approach, I'm looking for seconds. Seconded. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ signature.asc Description: Digital signature
Bug#514919: Removing support for uploads to multiple distributions
Raphael Hertzog hert...@debian.org writes: On Fri, 19 Jun 2009, Russ Allbery wrote: Here is an updated patch for stating that the Debian archive doesn't support listing multiple distributions in the *.changes file. This reduces the footnote of distributions to just a couple of examples and defers to the devref for everything else. If this looks like the right approach, I'm looking for seconds. Seconded. Thanks, I've applied this one for the next Policy release. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
Here is an updated patch for stating that the Debian archive doesn't support listing multiple distributions in the *.changes file. This reduces the footnote of distributions to just a couple of examples and defers to the devref for everything else. If this looks like the right approach, I'm looking for seconds. diff --git a/policy.sgml b/policy.sgml index 43cf4d6..528c4b9 100644 --- a/policy.sgml +++ b/policy.sgml @@ -3118,76 +3118,39 @@ Package: libc6 distribution(s) where this version of the package should be installed. Valid distributions are determined by the archive maintainers.footnote - Current distribution names are: + Example distribution names in the Debian archive used in + file.changes/file files are: taglist compact=compact - tagemstable/em/tag - item - This is the current released version of Debian - GNU/Linux. Once the distribution is - emstable/em only security fixes and other - major bug fixes are allowed. When changes are - made to this distribution, the release number is - increased (for example: 2.2r1 becomes 2.2r2 then - 2.2r3, etc). - /item - tagemunstable/em/tag item - This distribution value refers to the - emdevelopmental/em part of the Debian - distribution tree. New packages, new upstream - versions of packages and bug fixes go into the - emunstable/em directory tree. Download from - this distribution at your own risk. - /item - - tagemtesting/em/tag - item - This distribution value refers to the - emtesting/em part of the Debian distribution - tree. It receives its packages from the - unstable distribution after a short time lag to - ensure that there are no major issues with the - unstable packages. It is less prone to breakage - than unstable, but still risky. It is not - possible to upload packages directly to - emtesting/em. - /item - - tagemfrozen/em/tag - item - From time to time, the emtesting/em - distribution enters a state of code-freeze in - anticipation of release as a emstable/em - version. During this period of testing only - fixes for existing or newly-discovered bugs will - be allowed. The exact details of this stage are - determined by the Release Manager. + This distribution value refers to the + emdevelopmental/em part of the Debian distribution + tree. Most new packages, new upstream versions of + packages and bug fixes go into the emunstable/em + directory tree. /item tagemexperimental/em/tag item - The packages with this distribution value are - deemed by their maintainers to be high - risk. Oftentimes they represent early beta or - developmental packages from various sources that - the maintainers want people to try, but are not - ready to be a part of the other parts of the - Debian distribution tree. Download at your own - risk. + The packages with this distribution value are deemed + by their maintainers to be high risk. Oftentimes they + represent early beta or developmental packages from + various sources that the maintainers want people to + try, but are not ready to be a part of the other parts + of the Debian distribution tree. /item /taglist p - You should list emall/em distributions that the - package should be installed into. - /p - - p - More information is available in the Debian Developer's - Reference, section The Debian archive. + Others are used for updating stable releases or for + security uploads. More information is available in the + Debian Developer's Reference, section The Debian + archive. /p /footnote + The Debian archive software only
Bug#514919: Removing support for uploads to multiple distributions
Colin Watson writes (Bug#514919: Removing support for uploads to multiple distributions): The mythical dpkg programmer's manual? :-) The current policy manual was of course made by merging what I called the dpkg programmers' manual and what I called the policy manual. Regardless of what they're called, I agree the substance of them is important for the whole project and should be changed only with due consideration. I don't have an opinion about whether the code or the documentation should change first. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
On Thu, 2009-02-12 at 19:35 +, Mark Hymers wrote: In gmane.linux.debian.devel.policy, you wrote: I think it's worth mentioning in the policy footnote that the Debian archive doesn't (well, won't, to be entirely accurate) support the feature and removing the suggestion that there is a frozen distribution. As such, I'd be quite happy with Colin's suggested patch. I should also clarify that we might support it at the moment, but I've no idea if it actually works. It seems that we can either 1) make sure it works or 2) drop it from being supported (although as people have said, just in the debian-specific case). Either of these is fine by me, but relying on something which hasn't been tested for 5 years is probably not that sensible. My opinion should be obvious by now, but for the record I'd vote for option two. I can't see any merit in maintaining support for it in Debian and officially killing it removes any expectation that it might work. Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
On Fri, 2009-02-13 at 19:20 -0800, Russ Allbery wrote: Here's a proposed patch that limits the footnote to only discussing the values that go into *.changes files, removes extraneous information about the relative risk of unstable vs. testing, and mentions the other values commonly seen in the Distribution field for Debian packages. I also lifted the note that the Debian archive software doesn't support multiple distributions into the main text instead of a footnote, since it isn't just informative information. [...] + The emtesting/em distribution, which cannot be + uploaded to directly, normally receives its packages + from the emunstable/em distribution after a short + time lag. However sometimes, such as during release + freezes before a new stable release or when a problem + in the emtesting/em distribution requires fixing + before the emunstable/em version can migrate, + direct uploads to emtesting/em are useful. This + distribution value is used for those exceptions. That section sounds slightly strange to me. It starts by saying that one cannot upload directly to testing, and finishes by indicating that a distribution of t-p-u is used to upload directly to testing. Maybe something like + before the emunstable/em version can migrate, + direct updates to a package in emtesting/em are useful. + This distribution value is used for these exceptions, + after approval from the release managers. ? [...] + emstable-security/em and emtesting-securityem ^ / The rest looks good to me; thanks. Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
Adam D. Barratt a...@adam-barratt.org.uk writes: That section sounds slightly strange to me. It starts by saying that one cannot upload directly to testing, and finishes by indicating that a distribution of t-p-u is used to upload directly to testing. Maybe something like + before the emunstable/em version can migrate, + direct updates to a package in emtesting/em are useful. + This distribution value is used for these exceptions, + after approval from the release managers. ? [...] + emstable-security/em and emtesting-securityem ^ / The rest looks good to me; thanks. I now have: + The emtesting/em distribution normally receives + its packages via the emunstable/em distribution + after a short time lag. However sometimes, such as + during release freezes before a new stable release or + when a problem in the emtesting/em distribution + requires fixing before the emunstable/em version + can migrate, direct updates to a package in + emtesting/em are useful. This distribution value + is used for those exceptions, after approval from the + release managers. for that paragraph. Does that look better? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
On Sat, 2009-02-14 at 12:19 -0800, Russ Allbery wrote: I now have: + The emtesting/em distribution normally receives + its packages via the emunstable/em distribution + after a short time lag. However sometimes, such as + during release freezes before a new stable release or + when a problem in the emtesting/em distribution + requires fixing before the emunstable/em version + can migrate, direct updates to a package in + emtesting/em are useful. This distribution value + is used for those exceptions, after approval from the + release managers. for that paragraph. Does that look better? Yep, that all looks good to me; thanks. Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
On Sat, Feb 14, 2009 at 12:19:46PM -0800, Russ Allbery wrote: I now have: + The emtesting/em distribution normally receives + its packages via the emunstable/em distribution + after a short time lag. However sometimes, such as + during release freezes before a new stable release or + when a problem in the emtesting/em distribution + requires fixing before the emunstable/em version + can migrate, direct updates to a package in + emtesting/em are useful. This distribution value + is used for those exceptions, after approval from the + release managers. As far as I know, the archive maps uploads to testing to testing-proposed-updates, and so both end up in t-p-u. There is also testing-security, which first gets uploaded to security-master.debian.org and then also gets mapped to t-p-u when uploaded to ftp-master. But I wonder why we need such a list in policy. A few examples might be useful, but this more looks like something for the developers reference to me. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
Kurt Roeckx k...@roeckx.be writes: As far as I know, the archive maps uploads to testing to testing-proposed-updates, and so both end up in t-p-u. Yeah, but t-p-u is the recommended method, IIRC. There is also testing-security, which first gets uploaded to security-master.debian.org and then also gets mapped to t-p-u when uploaded to ftp-master. Those are mentioned briefly in a later paragraph that I didn't quote again. But I wonder why we need such a list in policy. A few examples might be useful, but this more looks like something for the developers reference to me. I agree that devref is canonical. The hard part about listing some examples is that I wasn't sure where to stop; there aren't that many that are really in use. Listing a couple of examples is most of the work of listing the four that we actually use (plus mentioning the security ones). But if people feel it would be better, I can trim the footnote even further. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
On Sat, 2009-02-14 at 22:59 +0100, Kurt Roeckx wrote: As far as I know, the archive maps uploads to testing to testing-proposed-updates, and so both end up in t-p-u. That's correct. The s-p-u and t-p-u uploads I've made for devscripts all had either stable or testing in the changelog. Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
Raphael Hertzog hert...@debian.org writes: Agreed. In the long term, I would like to move all the documentation about the syntax into dpkg itself and have the policy document how Debian uses dpkg rather than documenting dpkg itself. It's already in our TODO list to document the format of .dsc, .changes and debian/control. Personally, I think it would be a mistake to move the specification of file formats into dpkg documentation and out of Policy. It's one thing to move to dpkg documentation things that only dpkg cares about, but Policy is in essence the standards body and interface specification for the Debian packaging format, whereas dpkg is just one implementation. Currently it's the only implementation, but I think breaking down the distinction between specification and implementation is a bad thing in the long run. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
Colin Watson cjwat...@debian.org writes: However, I'm not convinced that it is correct to remove this feature from the *syntax*. While Ubuntu's archive maintenance software doesn't support it right now, several people have requested it (https://bugs.launchpad.net/soyuz/+bug/235064). If you're maintaining packages for a system that releases every six months, it turns out to be rather more likely in practice to be able to say that the same packages will work for several different releases, and less painful to maintain this state. .changes is a good format for interacting with Debian-format archives other than just Debian's, and this seems worth preserving. How about this patch instead (incorporating your fold of frozen into testing): I propose going a step farther. I think much of this footnote contains information that doesn't belong here. For one, it changes, and as we can tell from the lack of bug reports against Policy about it, this isn't where anyone looks for this information. For another, this is the section on the Distribution field in *.changes specifically, not on the Debian archive structure, so discussion of, for example, the testing distribution is really out of scope. Here's a proposed patch that limits the footnote to only discussing the values that go into *.changes files, removes extraneous information about the relative risk of unstable vs. testing, and mentions the other values commonly seen in the Distribution field for Debian packages. I also lifted the note that the Debian archive software doesn't support multiple distributions into the main text instead of a footnote, since it isn't just informative information. It has a practical effect on what people should put into their *.changes file: if they want something to go to both unstable and stable-proposed-updates, they need to know that listing both in *.changes isn't going to work. Without saying something in the main body of the text, Policy leaves one with the impression that Policy requires this to work. How does this look to everyone? diff --git a/policy.sgml b/policy.sgml index 36f51aa..969b5c7 100644 --- a/policy.sgml +++ b/policy.sgml @@ -3062,69 +3062,58 @@ Package: libc6 distribution(s) where this version of the package should be installed. Valid distributions are determined by the archive maintainers.footnote - Current distribution names are: + Current distribution names in the Debian archive used in + file.changes/file files are: taglist compact=compact - tagemstable/em/tag - item - This is the current released version of Debian - GNU/Linux. Once the distribution is - emstable/em only security fixes and other - major bug fixes are allowed. When changes are - made to this distribution, the release number is - increased (for example: 2.2r1 becomes 2.2r2 then - 2.2r3, etc). - /item - tagemunstable/em/tag item - This distribution value refers to the - emdevelopmental/em part of the Debian - distribution tree. New packages, new upstream - versions of packages and bug fixes go into the - emunstable/em directory tree. Download from - this distribution at your own risk. + This distribution value refers to the + emdevelopmental/em part of the Debian distribution + tree. Most new packages, new upstream versions of + packages and bug fixes go into the emunstable/em + directory tree. /item - tagemtesting/em/tag + tagemexperimental/em/tag item - This distribution value refers to the - emtesting/em part of the Debian distribution - tree. It receives its packages from the - unstable distribution after a short time lag to - ensure that there are no major issues with the - unstable packages. It is less prone to breakage - than unstable, but still risky. It is not - possible to upload packages directly to - emtesting/em. + The packages with this distribution value are deemed + by their maintainers to be high risk. Oftentimes they + represent early beta or developmental packages from + various sources that the maintainers want people to + try, but are not ready to be a part of the other parts + of the Debian distribution tree.
Bug#514919: Removing support for uploads to multiple distributions
Raphael Hertzog hert...@debian.org writes: It depends, and there can be some repetition when needed to ease the comprehension. But you don't need to know the .changes syntax to create policy conformant packages, you just have to know how to call dpgk-genchanges and what to put in debian/files and debian/changelog and debian/control. I think this would be an unfortunate direction to take. The ideal to strive for, in my opinion, is that one should be able to build a Policy-conformant Debian package using only information in Policy and standard UNIX tools. That you cannot currently do this I consider a bug in Policy that I want to fix. It's not horribly high-priority compared to other bugs, but I certainly don't agree with going the opposite direction. Even apart from the merits of having an independent specification and the stronger review process that Policy offers, there are practical benefits to having all the details in one place. Policy is intended to be a technical specification, not a how-to guide for packagers. We shouldn't be afraid of including the specific details even if there are standard tools that can take care of them for you. As we've discussed in the past on the dpkg mailing list, I'm personally unhappy at some recent moves towards changing how Debian packages are built within the dpkg tools without going through the Policy review process, and I think this sort of documentation shift would accelerate that trend. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
Russ Allbery wrote: Adam D. Barratt a...@adam-barratt.org.uk writes: The Policy section detailing the Distribution field in .changes files specifies that the field may contain a space-separated list of distributions. Whilst this is technically accurate, the feature has been deprecated since the testing distribution became an official part of the archive and is, imho, obsolete; the use case of uploading the same package to unstable and the frozen-stable-to-be as a single upload no longer applies. I discussed this with a couple of members of the ftpteam on IRC earlier today, and they were both in favour of removing support for the feature from dak. One of them had a dig through the archives and discovered that there have been no multiple-distribution uploads since 2004; even then there was only the one upload in that year, with the grand total of three in 2003. I would do a more radical change. (BTW I think ftp-team/DSA should update the footnote 38, and we should remove all). I think we should move distribution field from upload target to a final target distribution, i.e. a sort of quality assessment. I really don't like that maintainers fill a RC bug only to stop migrating a package from stable to testing. To distinguish different queues, I would use different upload URLs (like we had for non-us). But such proposal should eventually come from ftp-team. Nobody use it? Maybe we should ask people to use it, i.e. for the case of important fixes that should go *also* to backport. In conclusion: if this proposal will simplify dak tools I'll agree, in other case I'm undecided. This looks good to me in general. The only concern that I have is that there are other archive maintenance packages besides dak and some of them explicitly list multiple- distribution upload support as a feature (reprepro, for instance). Policy is specifically intended to describe the requirements for packages that are part of Debian, where dak matters the most, but this is specifically a description of the *.changes *syntax*. I'm a little unsure as to whether we should make multiple distributions a syntax error, when other tools support it, or instead just say that it's allowed in the syntax but the Debian archive doesn't support it. I think this is a general problem we the policy (that IMO should be fixed in the new policy): it is not clear (and it use the same restrictions) to both users, but IMHO packagers should have stricter rules, and dak/dpkg/... could have more relaxed rules (like the main internet rule). ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
In gmane.linux.debian.devel.policy, you wrote: I think we should move distribution field from upload target to a final target distribution, i.e. a sort of quality assessment. I really don't like that maintainers fill a RC bug only to stop migrating a package from stable to testing. ^^ I assume you mean unstable To distinguish different queues, I would use different upload URLs (like we had for non-us). But such proposal should eventually come from ftp-team. dak doesn't deal with moving packages from unstable to testing, that's for britney to decide (under the control of the release team). Ultimately, as I understand it, the current position is that packages not aimed at testing shouldn't go to unstable anyways (as they may tie up migration of other packages through shlib changes or other problems) but should be placed in experimental instead. Nobody use it? Maybe we should ask people to use it, i.e. for the case of important fixes that should go *also* to backport. As backport.org is an entirely seperate archive, that wouldn't work (unless we re-injected the package into the backport.org queued, but that would require us to 1) know about it and 2) not feel ill at the prospect of doing things like that :-) Cheers, Mark PS - Sorry if this goes wrong, but this is the first time I've replied to a lists mail having read it via news - chances of failure are high. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
On Wed, Feb 11, 2009 at 09:27:17PM +, Adam D. Barratt wrote: The Policy section detailing the Distribution field in .changes files specifies that the field may contain a space-separated list of distributions. Whilst this is technically accurate, the feature has been deprecated since the testing distribution became an official part of the archive and is, imho, obsolete; the use case of uploading the same package to unstable and the frozen-stable-to-be as a single upload no longer applies. I discussed this with a couple of members of the ftpteam on IRC earlier today, and they were both in favour of removing support for the feature from dak. One of them had a dig through the archives and discovered that there have been no multiple-distribution uploads since 2004; even then there was only the one upload in that year, with the grand total of three in 2003. For Debian's archive, I think this change is entirely reasonable. However, I'm not convinced that it is correct to remove this feature from the *syntax*. While Ubuntu's archive maintenance software doesn't support it right now, several people have requested it (https://bugs.launchpad.net/soyuz/+bug/235064). If you're maintaining packages for a system that releases every six months, it turns out to be rather more likely in practice to be able to say that the same packages will work for several different releases, and less painful to maintain this state. .changes is a good format for interacting with Debian-format archives other than just Debian's, and this seems worth preserving. How about this patch instead (incorporating your fold of frozen into testing): diff --git a/policy.sgml b/policy.sgml index 36f51aa..78f2346 100644 --- a/policy.sgml +++ b/policy.sgml @@ -3096,10 +3096,6 @@ Package: libc6 than unstable, but still risky. It is not possible to upload packages directly to emtesting/em. - /item - - tagemfrozen/em/tag - item From time to time, the emtesting/em distribution enters a state of code-freeze in anticipation of release as a emstable/em @@ -3124,7 +3120,9 @@ Package: libc6 p You should list emall/em distributions that the - package should be installed into. + package should be installed into. Note, however, that + the Debian archive only supports listing a single + distribution. /p p -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
On Thu, 12 Feb 2009, Colin Watson wrote: However, I'm not convinced that it is correct to remove this feature from the *syntax*. While Ubuntu's archive maintenance software doesn't support it right now, several people have requested it (https://bugs.launchpad.net/soyuz/+bug/235064). If you're maintaining packages for a system that releases every six months, it turns out to be rather more likely in practice to be able to say that the same packages will work for several different releases, and less painful to maintain this state. .changes is a good format for interacting with Debian-format archives other than just Debian's, and this seems worth preserving. Agreed. In the long term, I would like to move all the documentation about the syntax into dpkg itself and have the policy document how Debian uses dpkg rather than documenting dpkg itself. It's already in our TODO list to document the format of .dsc, .changes and debian/control. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
* Adam D. Barratt a...@adam-barratt.org.uk [090211 22:30]: The Policy section detailing the Distribution field in .changes files specifies that the field may contain a space-separated list of distributions. Whilst this is technically accurate, the feature has been deprecated since the testing distribution became an official part of the archive and is, imho, obsolete; the use case of uploading the same package to unstable and the frozen-stable-to-be as a single upload no longer applies. I discussed this with a couple of members of the ftpteam on IRC earlier today, and they were both in favour of removing support for the feature from dak. One of them had a dig through the archives and discovered that there have been no multiple-distribution uploads since 2004; even then there was only the one upload in that year, with the grand total of three in 2003. I agree that this is no longer needed within Debian, but I think it is still a usefull feature and use it a lot in local repositories, so would like to have changes handling tools continue to support it. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
On Thu, Feb 12, 2009 at 03:21:28PM +0100, Raphael Hertzog wrote: On Thu, 12 Feb 2009, Colin Watson wrote: However, I'm not convinced that it is correct to remove this feature from the *syntax*. While Ubuntu's archive maintenance software doesn't support it right now, several people have requested it (https://bugs.launchpad.net/soyuz/+bug/235064). If you're maintaining packages for a system that releases every six months, it turns out to be rather more likely in practice to be able to say that the same packages will work for several different releases, and less painful to maintain this state. .changes is a good format for interacting with Debian-format archives other than just Debian's, and this seems worth preserving. Agreed. In the long term, I would like to move all the documentation about the syntax into dpkg itself and have the policy document how Debian uses dpkg rather than documenting dpkg itself. The mythical dpkg programmer's manual? :-) I was never all that convinced. I do think there's value in the policy manual being coherent in itself, rather than depending on another manual for all the syntax. (I realise you already need to learn make and what-have-you, but it's currently fairly complete in terms of the things you need to build Debian packages on top of standard Unix tools.) -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
On Thu, 12 Feb 2009, Colin Watson wrote: In the long term, I would like to move all the documentation about the syntax into dpkg itself and have the policy document how Debian uses dpkg rather than documenting dpkg itself. The mythical dpkg programmer's manual? :-) We do have quite a lot of documentation in dpkg already. All tools are extensively documented. Only file formats are not well covered. But we do have: deb-substvars(5), deb-shlibs(5), deb-triggers(5), deb-control(5), deb-version(5), deb(5), deb-override(5) and deb-symbols(5). We need deb-changes(5), deb-dsc(5) and deb-src-control(5). I was never all that convinced. I do think there's value in the policy manual being coherent in itself, rather than depending on another manual for all the syntax. (I realise you already need to learn make and It depends, and there can be some repetition when needed to ease the comprehension. But you don't need to know the .changes syntax to create policy conformant packages, you just have to know how to call dpgk-genchanges and what to put in debian/files and debian/changelog and debian/control. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
On Wed, Feb 11, 2009 at 08:22:45PM -0800, Russ Allbery wrote: Adam D. Barratt a...@adam-barratt.org.uk writes: The Policy section detailing the Distribution field in .changes files specifies that the field may contain a space-separated list of distributions. Whilst this is technically accurate, the feature has been deprecated since the testing distribution became an official part of the archive and is, imho, obsolete; the use case of uploading the same package to unstable and the frozen-stable-to-be as a single upload no longer applies. I discussed this with a couple of members of the ftpteam on IRC earlier today, and they were both in favour of removing support for the feature from dak. One of them had a dig through the archives and discovered that there have been no multiple-distribution uploads since 2004; even then there was only the one upload in that year, with the grand total of three in 2003. This looks good to me in general. The only concern that I have is that there are other archive maintenance packages besides dak and some of them explicitly list multiple- distribution upload support as a feature (reprepro, for instance). Policy is specifically intended to describe the requirements for packages that are part of Debian, where dak matters the most, but this is specifically a description of the *.changes *syntax*. I'm a little unsure as to whether we should make multiple distributions a syntax error, when other tools support it, or instead just say that it's allowed in the syntax but the Debian archive doesn't support it. I agree that dak not currently supporting multiple-distribution upload is not a reason to change policy about the format of the .changes files, since this is well supported by dpkg and other tools and can be useful with other upload queues. Furthermore, generally, dak behaviour is not documented in Policy, but rather in the Developers reference and this suggest that this changes be documented there. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
On Thu, 2009-02-12 at 19:11 +0100, Bill Allombert wrote: I agree that dak not currently supporting multiple-distribution upload is not a reason to change policy about the format of the .changes files, since this is well supported by dpkg and other tools and can be useful with other upload queues. Yep, I've been more than convinced on that score by various replies already. Furthermore, generally, dak behaviour is not documented in Policy, but rather in the Developers reference and this suggest that this changes be documented there. I think it's worth mentioning in the policy footnote that the Debian archive doesn't (well, won't, to be entirely accurate) support the feature and removing the suggestion that there is a frozen distribution. As such, I'd be quite happy with Colin's suggested patch. Cheers, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
In gmane.linux.debian.devel.policy, you wrote: I think it's worth mentioning in the policy footnote that the Debian archive doesn't (well, won't, to be entirely accurate) support the feature and removing the suggestion that there is a frozen distribution. As such, I'd be quite happy with Colin's suggested patch. I should also clarify that we might support it at the moment, but I've no idea if it actually works. It seems that we can either 1) make sure it works or 2) drop it from being supported (although as people have said, just in the debian-specific case). Either of these is fine by me, but relying on something which hasn't been tested for 5 years is probably not that sensible. Mark -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
Package: debian-policy Version: 3.8.1.0 Severity: wishlist Hi, The Policy section detailing the Distribution field in .changes files specifies that the field may contain a space-separated list of distributions. Whilst this is technically accurate, the feature has been deprecated since the testing distribution became an official part of the archive and is, imho, obsolete; the use case of uploading the same package to unstable and the frozen-stable-to-be as a single upload no longer applies. I discussed this with a couple of members of the ftpteam on IRC earlier today, and they were both in favour of removing support for the feature from dak. One of them had a dig through the archives and discovered that there have been no multiple-distribution uploads since 2004; even then there was only the one upload in that year, with the grand total of three in 2003. I propose the following patch, against current git (I also took the opportunity to fold the old frozen distribution information into the testing section): diff --git a/policy.sgml b/policy.sgml index 36f51aa..66466c8 100644 --- a/policy.sgml +++ b/policy.sgml @@ -3058,10 +3058,9 @@ Package: libc6 p In a file.changes/file file or parsed changelog output - this contains the (space-separated) name(s) of the - distribution(s) where this version of the package should - be installed. Valid distributions are determined by the - archive maintainers.footnote + this contains the name of the distribution where this version + of the package should be installed. Valid distributions are + determined by the archive maintainers.footnote Current distribution names are: taglist compact=compact tagemstable/em/tag @@ -3096,10 +3095,7 @@ Package: libc6 than unstable, but still risky. It is not possible to upload packages directly to emtesting/em. - /item - tagemfrozen/em/tag - item From time to time, the emtesting/em distribution enters a state of code-freeze in anticipation of release as a emstable/em @@ -3123,11 +3119,6 @@ Package: libc6 /taglist p - You should list emall/em distributions that the - package should be installed into. - /p - - p More information is available in the Debian Developer's Reference, section The Debian archive. /p Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
Adam D. Barratt a...@adam-barratt.org.uk writes: The Policy section detailing the Distribution field in .changes files specifies that the field may contain a space-separated list of distributions. Whilst this is technically accurate, the feature has been deprecated since the testing distribution became an official part of the archive and is, imho, obsolete; the use case of uploading the same package to unstable and the frozen-stable-to-be as a single upload no longer applies. I discussed this with a couple of members of the ftpteam on IRC earlier today, and they were both in favour of removing support for the feature from dak. One of them had a dig through the archives and discovered that there have been no multiple-distribution uploads since 2004; even then there was only the one upload in that year, with the grand total of three in 2003. This looks good to me in general. The only concern that I have is that there are other archive maintenance packages besides dak and some of them explicitly list multiple- distribution upload support as a feature (reprepro, for instance). Policy is specifically intended to describe the requirements for packages that are part of Debian, where dak matters the most, but this is specifically a description of the *.changes *syntax*. I'm a little unsure as to whether we should make multiple distributions a syntax error, when other tools support it, or instead just say that it's allowed in the syntax but the Debian archive doesn't support it. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
