Re: Bits from the dpkg maintainer
[I am not subscribed to debian-devel, please Cc: me if you feel your reply deserves my attention.] On Mon, 2005-06-13 at 10:10 +0200, Peter Palfrader wrote: On Sun, 12 Jun 2005, Wesley J. Landaker wrote: The basics of the new format are: * Multiple upstream tarballs are supported: * The Debian Diff may be replaced by the Debian Tar: * Bzip2 compression is supported as an alternative to gzip. As a practical matter, how soon will these really be supported in Debian? Is dpkg change all that is needed? i.e. Could I upload a new revision of a package that has multiple upstream tarballs, and a debian.tar.bz2 right now, or are there a lot of other things that have to change first? Historically we always wanted to be able to use all the source in the archive with the tools available in stable. If that policy is still true you would be able to use the new features by the time edge releases with the new dpkg. That is in some 10 to 18 months :) That's sadly totally untrue. Either you mean use all the source in the archive with the DPKG-DEV available in stable -- or it was utterly violated by all the packages in the sarge period that used (e.g.) debhelper features available in woody. It's no harder to backport dpkg-dev than it is debhelper; so I think it really just comes down to what formats the FTP masters (and dear katie) are prepared to accept. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: Bits from the dpkg maintainer
Hi Scott, On Tue, Jun 14, 2005 at 08:30:07AM +0100, Scott James Remnant wrote: It's no harder to backport dpkg-dev than it is debhelper; so I think it really just comes down to what formats the FTP masters (and dear katie) are prepared to accept. Are you pushing for this or just seeing what's going to happen? Do you know if Ubuntu going to support the new format during etch's testing phase (say 18 months for argument's sake)? Simon. -- * They were trying to manipulate behaviour. Alter people's * | decision making - what to buy, who to vote for .. - Mulder | * You think they'll stop at commerce or politics? - X * Brought to you by the letter G and the number 29 signature.asc Description: Digital signature
Re: Bits from the dpkg maintainer
On Tue, Jun 14, 2005 at 08:30:07AM +0100, Scott James Remnant wrote: Historically we always wanted to be able to use all the source in the archive with the tools available in stable. If that policy is still true you would be able to use the new features by the time edge releases with the new dpkg. That is in some 10 to 18 months :) That's sadly totally untrue. Either you mean use all the source in the archive with the DPKG-DEV available in stable Yes, that's what we mean. The reason is that for various things (e.g., buildd, ftp-mastery, ...), we need to be able to manipulate source packages with the tools in stable. Note, I said manipulate, not build. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond signature.asc Description: Digital signature
Re: Bits from the dpkg maintainer
On Tue, 2005-06-14 at 09:18 +0100, Simon Huggins wrote: On Tue, Jun 14, 2005 at 08:30:07AM +0100, Scott James Remnant wrote: It's no harder to backport dpkg-dev than it is debhelper; so I think it really just comes down to what formats the FTP masters (and dear katie) are prepared to accept. Are you pushing for this or just seeing what's going to happen? Do you know if Ubuntu going to support the new format during etch's testing phase (say 18 months for argument's sake)? I'm not particularly pushing, in the sense that pushing within Debian would involve writing the patches to katie etc. myself and I don't really have the time to do that. I'm leaning and gesticulating wildly in that direction though. Ubuntu has a 6-monthly release schedule, so they're almost certain to adopt new formats before Debian. A good example is the fact that Ubuntu shipped bz2-compressed debs in hoary for a few packages that benefited from it, and Debian doesn't even allow them to be uploaded. While I don't know what Ubuntu's plans are, because I'm as equally uninvolved in those as I am with Debian, I would not be surprised if their maintainers chose to adopt it for their source packages once build support is available. Though I wouldn't expect them to convert things. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: Bits from the dpkg maintainer
On Tue, 2005-06-14 at 11:20 +0200, Wouter Verhelst wrote: On Tue, Jun 14, 2005 at 08:30:07AM +0100, Scott James Remnant wrote: Historically we always wanted to be able to use all the source in the archive with the tools available in stable. If that policy is still true you would be able to use the new features by the time edge releases with the new dpkg. That is in some 10 to 18 months :) That's sadly totally untrue. Either you mean use all the source in the archive with the DPKG-DEV available in stable Yes, that's what we mean. The reason is that for various things (e.g., buildd, ftp-mastery, ...), we need to be able to manipulate source packages with the tools in stable. Note, I said manipulate, not build. Why can't you just install the unstable ones? Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: Bits from the dpkg maintainer
On Tue, Jun 14, 2005 at 10:39:30AM +0100, Scott James Remnant wrote: Yes, that's what we mean. The reason is that for various things (e.g., buildd, ftp-mastery, ...), we need to be able to manipulate source packages with the tools in stable. Note, I said manipulate, not build. Why can't you just install the unstable ones? Because we don't run unstable on our project machines for a reason? -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the dpkg maintainer
On Tue, 2005-06-14 at 11:50 +0200, Wouter Verhelst wrote: On Tue, Jun 14, 2005 at 10:39:30AM +0100, Scott James Remnant wrote: Yes, that's what we mean. The reason is that for various things (e.g., buildd, ftp-mastery, ...), we need to be able to manipulate source packages with the tools in stable. Note, I said manipulate, not build. Why can't you just install the unstable ones? Because we don't run unstable on our project machines for a reason? You don't have to run everything unstable, you know; just the bits you want. An 18-month delay between features being implemented and used fundamentally results in an 18-month delay between them being implemented and _TESTED_. In other words, adding features to dpkg/dpkg-dev in unstable and then waiting for them to go into stable before using them means that the bugs aren't found until the feature is already in stable and thus unfixable until the next stable release. A recent example of this would be #313400, which has only just been noticed despite the implementation being 6-months old. Yet this has major consequences. Another example would be the fact that the bzip2-compressed deb support was broken, and it was only because Ubuntu decided to use it that we discovered this. We would have shipped non-working support in stable, and had to wait another 18+ months before it was useful. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: Bits from the dpkg maintainer
On Tue, Jun 14, 2005 at 11:50:43AM +0200, Wouter Verhelst wrote: On Tue, Jun 14, 2005 at 10:39:30AM +0100, Scott James Remnant wrote: Yes, that's what we mean. The reason is that for various things (e.g., buildd, ftp-mastery, ...), we need to be able to manipulate source packages with the tools in stable. Note, I said manipulate, not build. Why can't you just install the unstable ones? Because we don't run unstable on our project machines for a reason? That's right. We use backports.org. Cheers, Pasc -- Pascal Hakim 0403 411 672 Do Not Bend -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the dpkg maintainer
Scott James Remnant wrote: Yes, that's what we mean. The reason is that for various things (e.g., buildd, ftp-mastery, ...), we need to be able to manipulate source packages with the tools in stable. Note, I said manipulate, not build. Why can't you just install the unstable ones? For comparison, the unstable versions of both dak and debbugs *trail* the versions actually used on ftp-master.d.o and bugs.d.o. The recent debootstrap changes are a pretty strong encouragement to use a newer version of apt on ftp-master than is currently in unstable (or experimental for that matter) to release etch, too. For core infrastructure, running the latest working version just makes sense; whether it's released as stable or not. The only reason to delay using features until they're in stable is for users' benefit: eg, if something stops you being able to upgrade to etch from sarge, that would suck. I can't see any particular reason to delay the new source format. Reasons to speed it up, otoh... Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the dpkg maintainer
On Tue, 14 Jun 2005 08:30:07 +0100, Scott James Remnant [EMAIL PROTECTED] said: That's sadly totally untrue. Either you mean use all the source in the archive with the DPKG-DEV available in stable -- or it was utterly violated by all the packages in the sarge period that used (e.g.) debhelper features available in woody. It's no harder to backport dpkg-dev than it is debhelper; so I think it really just comes down to what formats the FTP masters (and dear katie) are prepared to accept. Umm. While true, I consider this unfortunate (part of my rant on helper packages in general), and I would prefer we did not make selective single package backporting an exercise in recompiling large chunks of the release. I understand that there are times when one needs to backport other packages (which is why they are called dependencies, yes) as well, but we should try an minimize coupling. It would be nice is we tried to actively make the situation better, rather than pointing to current obstacles and using them as justification for making matter worse. Tight coupling in modular systems is not something to be encouraged. manoj -- In matrimony, to hesitate is sometimes to be saved. Butler Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the dpkg maintainer
On Sun, 12 Jun 2005, Wesley J. Landaker wrote: The basics of the new format are: * Multiple upstream tarballs are supported: * The Debian Diff may be replaced by the Debian Tar: * Bzip2 compression is supported as an alternative to gzip. As a practical matter, how soon will these really be supported in Debian? Is dpkg change all that is needed? i.e. Could I upload a new revision of a package that has multiple upstream tarballs, and a debian.tar.bz2 right now, or are there a lot of other things that have to change first? Historically we always wanted to be able to use all the source in the archive with the tools available in stable. If that policy is still true you would be able to use the new features by the time edge releases with the new dpkg. That is in some 10 to 18 months :) -- PGP signed and encrypted | .''`. ** Debian GNU/Linux ** messages preferred.| : :' : The universal | `. `' Operating System http://www.palfrader.org/ | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the dpkg maintainer
ma, 2005-06-13 kello 10:10 +0200, Peter Palfrader kirjoitti: Historically we always wanted to be able to use all the source in the archive with the tools available in stable. If that policy is still true you would be able to use the new features by the time edge releases with the new dpkg. That is in some 10 to 18 months :) Unless we update sarge with a new version of dpkg that can handle the new source format, of course. ;-) That is, however, probably a bad idea. dpkg it too critical a piece for a Debian system for us to muck about it more than we have to, in a stable release. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the dpkg maintainer
On Sun, 12 Jun 2005 21:05:56 +0100, Scott James Remnant wrote: [...] * The Debian Diff may be replaced by the Debian Tar: Instead of placing your changes and Debian directory as a patch against the upstream tarball in a diff.gz, you may instead ship the Debian directory as a debian.tar.gz. This is unpacked into the debian sub-directory of the source. This is beautiful. I can't count the number of times I've looked at a random package that has multiple fixes and enhancement all in the diff.gz, with no way of knowing what bugs in the BTS they fix, which hunks are are logically separate, etc. Even worse are the packages which include broken out patches in the debian directory which are out of date or incomplete, and no longer match what's in the diff.gz. It's analogous to programs which have no documentation, incomplete documentation, or worse yet, completely incorrect documentation. I'm sure people will still find ways to make other DDs lives difficult in this manner (everything being in one big patch, including fixes in the orig tarball, or something equally as stupid), but this seems like this will go a long way to encourages people to separate out upstream enhancement/fixes. As an added bonus, this is how I typically do development (which is similar to how HCT does stuff under the hood, from what I've seen), so that debian-directory-specific baz/git/$RCS branch will now map directly to a tarball, and individual patches in debian/patches will map to their respective branches. /me wipes a tear of joy from his eye -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the dpkg maintainer
On Sunday 12 June 2005 14:05, Scott James Remnant wrote: The Wig Pen (Format: 2.0) source format is an evolutionary (rather than revolutionary) change to the current source package format. Brendan O'Dea's work on providing _unpack_ support has been integrated into dpkg-source. Support for building these formats will be added as it matures and solidifies. Existing source packages (Format: 1.0) are supported without modification. The basics of the new format are: * Multiple upstream tarballs are supported: [...] * The Debian Diff may be replaced by the Debian Tar: [...] * Bzip2 compression is supported as an alternative to gzip. As a practical matter, how soon will these really be supported in Debian? Is dpkg change all that is needed? i.e. Could I upload a new revision of a package that has multiple upstream tarballs, and a debian.tar.bz2 right now, or are there a lot of other things that have to change first? -- Wesley J. Landaker [EMAIL PROTECTED] OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 pgptV69LqTwng.pgp Description: PGP signature
