Re: Recent changes in dpkg
On Tue, 01 Jun 2010, Jonathan Niehof wrote: This is a great addition; however, if the user has changed the conffile *and* the maintainer also changes it in the same version where it is moved, the user's file is left silently in place and the maintainer's installed as .dpkg-new. This seems surprising to me, as it means the behavior is different when the conffile moves than when it doesn't (if it hadn't moved, a question would be triggered). I had this issue with the recipes in http://wiki.debian.org/DpkgConffileHandling to start with, so it's not a knock on dpkg-maintscript-helper itself. I have an approach that does a three-way compare between old maintainer, new maintainer, and user versions and tries to be smart about it. If this behaviour is desirable I'll see if I can't make a patch for dpkg-maintscript-helper. (The cost is a hacky sed line in rules which rewrites prerm with the md5 of the new maintainer version.) I think this ought to be fixed, yes. The sed call is not really needed, you can hardcode the md5sum in the parameters, it's not going to change over time. It would be even better if this could be extracted at run time (technically it can, you can extract it in the prerm from /var/lib/dpkg/info/tmp.ci/conffiles, it's just a question whether we want to support such an interface as this is mucking with dpkg's internals. But it's less of a problem now since dpkg-maintscript-helper is tied to dpkg anyway). In any case, please file a bug report (with a patch if you can). Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100602060835.gb...@rivendell
Re: Recent changes in dpkg
On Mon, May 24, 2010 at 5:05 AM, Raphael Hertzog hert...@debian.org wrote: * The dpkg-maintscript-helper tool has been introduced in dpkg 1.15.7.2 to help packagers deal with renaming conffiles and removing obsolete conffiles. This is a great addition; however, if the user has changed the conffile *and* the maintainer also changes it in the same version where it is moved, the user's file is left silently in place and the maintainer's installed as .dpkg-new. This seems surprising to me, as it means the behavior is different when the conffile moves than when it doesn't (if it hadn't moved, a question would be triggered). I had this issue with the recipes in http://wiki.debian.org/DpkgConffileHandling to start with, so it's not a knock on dpkg-maintscript-helper itself. I have an approach that does a three-way compare between old maintainer, new maintainer, and user versions and tries to be smart about it. If this behaviour is desirable I'll see if I can't make a patch for dpkg-maintscript-helper. (The cost is a hacky sed line in rules which rewrites prerm with the md5 of the new maintainer version.) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktilbzrketve4wnkf1z6vlbrgqg9vlabvkeaz3...@mail.gmail.com
Re: Recent changes in dpkg
On Thu, May 27, 2010 at 07:45:30PM -0400, James Vega wrote:
On Thu, May 27, 2010 at 10:47:47PM +0200, Thomas Weber wrote:
How many packages are we talking about here? Is there a way to get the
number of packages that have the same version in Lenny and Squeeze?
According to a quick query on UDD, there are 3169 source packages which
have the same source version in Lenny and Squeeze. 746 when comparing
Etch and Squeeze.
Following up on this (thanks James):
I would be grateful if someone could check the following queries (i.e.,
if they do what the comment says they do):
-- up-to-date packages with same version in lenny and squeeze
---
SELECT count(s1.source) FROM sources s1, sources s2, dehs dehs
WHERE s1.source = s2.source
AND s1.version = s2.version
AND s1.release = 'lenny'
AND s2.release = 'squeeze'
AND s1.source = dehs.source
AND dehs.unstable_status = 'uptodate';
Result: 1059
-- Number of packages that didn't have any bugs ever, are uptodate and
-- not orphaned
---
SELECT count(*) FROM (
SELECT s1.source FROM sources s1, sources s2, dehs dehs
WHERE s1.source = s2.source
AND s1.version = s2.version
AND s1.release = 'lenny'
AND s2.release = 'squeeze'
AND s1.source = dehs.source
AND dehs.unstable_status = 'uptodate'
) AS psources
WHERE psources.source NOT IN (SELECT bugs.source FROM bugs)
AND psources.source NOT IN (SELECT source FROM orphaned_packages)
;
Result: 634
-- Number of packages that have only closed bugs, are up-to-date and not
-- orphaned
---
SELECT count(*) FROM (
SELECT s1.source FROM sources s1, sources s2, dehs dehs
WHERE s1.source = s2.source
AND s1.version = s2.version
AND s1.release = 'lenny'
AND s2.release = 'squeeze'
AND s1.source = dehs.source
AND dehs.unstable_status = 'uptodate'
) AS psources
WHERE psources.source IN (
SELECT bugs.source FROM bugs
WHERE bugs.status IN ('done', 'fixed')
)
AND psources.source NOT IN (SELECT source FROM orphaned_packages)
;
Result: 55
---
So, we are talking about 1000 packages which are up-to-date in
unstable currently. Bugs don't change that picture much. I consider this
manageable during a full cycle.
And frankly, arguing back and forth about this is an exercise in
futility:
Is the new format worse than the old one? No.
Does it offer advantages over the old one? Yes, maybe not for all
packages, but for some.
So, let's make life easier for the dpkg developers and convert our
packages. It's not that much of a burden (From my experience, it's far
less work than even the most trivial bug fix).
Thomas
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100529121727.ga28...@atlan
Re: Recent changes in dpkg
On Thu, 27 May 2010 21:36:17 +0200, Jean-Christophe Dubacq jcduba...@free.fr wrote: On 27/05/2010 21:17, Tollef Fog Heen wrote: I wasn't around for the libc5 = libc6 transition, but my understanding is it was larger than 20% of the archive. I would guesstimate the removal of /usr/X11R6 at being around the 20% mark (including binNMUs and all). So while they're uncommon, they're not unheard of. There is also the /usr/doc = /usr/share/doc transition. This took four releases, iirc. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1oinnw-0004kv...@swivel.zugschlus.de
Re: Recent changes in dpkg
On Sat, May 29, 2010 at 02:17:27PM +0200, Thomas Weber wrote: So, we are talking about 1000 packages which are up-to-date in unstable currently. Bugs don't change that picture much. I consider this manageable during a full cycle. And frankly, arguing back and forth about this is an exercise in futility: Is the new format worse than the old one? No. Does it offer advantages over the old one? Yes, maybe not for all packages, but for some. So, let's make life easier for the dpkg developers and convert our packages. There's no requirement to convert packages. All that's being requested is that the package be explicit about the source format. There's no reason to perform an upload *just* to make that change. There are currently 11.7k source packages which aren't explicitly declaring their source format. That's not going to change overnight and the Dpkg developers have already stated that the deprecation of an implied source format is a long term goal (likely Squeeze+2). -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org signature.asc Description: Digital signature
Re: Recent changes in dpkg
Le jeudi 27 mai 2010 à 13:38 -0500, Peter Samuelson a écrit : It's pretty clear that this is social engineering. The dpkg maintainers want to force every package maintainer to _think_ about which source format they wish to use. To ensure that, in the long run, you no longer have the choice to simply ignore the format war. I am puzzled by one thing, however. There is another thing that puzzles me: that people think there is a format war. We have a new format that is better in all respects. Let’s just migrate to it. We can take 2, even 3 releases if it’s what it takes, but there’s just one day when it becomes pointless to support an old format. Face it: in a few years, no one will care about the 1.0 format anymore, regardless of how much virulent they are today. Raphaël didn’t always do a good communication job around this format and maybe not all changes were introduced in the right order. But now people are using this as an excuse for something I know very well from work: change resistance. Whatever change you implement, some people will actively work against it, generally with no rational reason. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: Recent changes in dpkg
On 2010-05-26, Holger Levsen hol...@layer-acht.org wrote: On Mittwoch, 26. Mai 2010, Philipp Kern wrote: ETOPIC. You have to specify the format in the package. Nowhere they write that 1.0 will disappear. And they say in the long term too, so debian/source/format should be propagating naturally into most of the packages due to the lintian tag. And I haven't heard of a single reason, why the lack of debian/source/format *shouldn't* be interpreted as, well, source/format 1.0. As far as I understood it, it's not that much about unpacking, because the format is pretty clear then, but about packing (or in this case repacking) the source package. There you should be explicit in what you mean because future versions of dpkg might abort if the source version is not explicitly specified in the package. Now I think the maintainers did outline why they want that in the past. :P Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnhvs38n.k0b.tr...@kelgar.0x539.de
Re: Recent changes in dpkg
On Thu, 27 May 2010 00:16:01 +0200 Emilio Pozuelo Monfort po...@debian.org wrote: Putting the list back into the loop. On 26/05/10 23:34, Neil Williams wrote: Declaring a format mandates touching every single package because the vast majority of packages are currently dpkg source format 1.0 ONLY because debian/source/format does NOT exist. The dpkg maintainers appear to want all packages to have a file that currently only exists in a fraction of packages. We cannot add a file to packages without touching them / rebuilding them, so as the lack of a file is proposed as being *against eventual policy* then Policy is being abused to do what it has been claimed Policy should never do - force a change that is NOT already implemented in most affected packages. No, the idea is that you add debian/source/format when you need to upload the package (and not the other way round), so this will just be an slow transition. There are packages that don't need uploads again. These packages are nor orphaned, not dead upstream, just very stable. Policy is not going to require debian/source/format anytime soon, so that's irrelevant. Not if the package then FTBFS. You seem to think that every package is going to be uploaded just for the sake of an upload. There is no way to guarantee that ALL packages in Debian will be uploaded again by some point in the future. If a package does not need an upload - e.g. the only issue is an ancient standards version - then dpkg cannot change behaviour in a way that makes that package FTBFS. The ABSENCE of debian/source/format needs to be explicitly retained as a de facto declaration of dpkg source format 1.0. i.e. unless explicitly specified, 1.0 needs to BE the default. No, it doesn't. It is now but at some point there won't be any default, meaning that if you don't have debian/source/format, dpkg will error out. Nothing wrong with that. If, eventually, dpkg fails with an error when debian/source/format does not exist, dpkg is causing the package to FTBFS and therefore dpkg is causing an unnecessary upload due to the changed behaviour of dpkg. There is A LOT wrong with that. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpeqIh49OXii.pgp Description: PGP signature
Re: Recent changes in dpkg
On Wed, 26 May 2010 23:44:52 +0200 Iustin Pop iu...@k1024.org wrote: On Wed, May 26, 2010 at 10:34:32PM +0100, Neil Williams wrote: I think the announcement is wrong, we cannot ever expect every single package to be touched for any single change. We don't even do that when libc changes SONAME - that only affects compiled packages, this theoretically affects all source packages which means huge numbers of rebuilds and transitions. Agreed. There is nothing wrong with a source package that glides through several stable releases without needing a rebuild, especially if it only builds an Arch:all binary package. As long as it is bug free, an ancient standards version alone is not sufficient reason to change anything in the package or make any upload just for the sake of making an upload. But here I disagree. A couple of stable releases is, let's say, 4 years? In the last four years, there have been significant changes (advancements?) in the state of Debian packaging. As such, most, if not all, nontrivial packages would be improved if they're brought up to date. I can think of a few perl modules that won't need another upload until Perl6 is not only released but sufficiently stable that Perl5 is to be removed. That doesn't look like it will happen within a couple of stable releases, if at all. (It will take us longer to transition from Perl5 than it did for libgtk1.2 and that took more than two stable releases.) Other packages affected could be data packages etc. After Squeeze is released, I'll have half a dozen or more packages that will be the same version in oldstable through to unstable and none of those currently have any bugs or lintian warnings other than an old/ancient standards version or similarly minor issues. None of those would give any benefits *to users* by being updated with respect to the packaging. debian/source/format cannot become mandatory without causing every single source package to be modified. For what? Just to add 6 bytes? Mandatory? I agree it shouldn't be mandatory. I would rather propose a 'W' lintian tag, nothing more, and which will only fire if the last changelog date is after the date this proposal goes live. If dpkg errors out upon the absence of debian/source/format, then it becomes mandatory by definition - because dpkg would cause a FTBFS through no fault of the package. I don't see any point in threatening to cause so many bugs merely to satisfy the dpkg maintainers. If it is going to be possible for dpkg to consider the absence of debian/source/format as an error, it is SO far ahead into the future that it isn't worth consideration IMHO. So the lack of a debian/source/format file has to remain supported by dpkg for more than a couple of stable releases, maybe with a message but NOT with a failure. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpSzxVWuIH2n.pgp Description: PGP signature
Re: Recent changes in dpkg
On Thu, 27 May 2010 06:11:36 + (UTC) Philipp Kern tr...@philkern.de wrote: On 2010-05-26, Holger Levsen hol...@layer-acht.org wrote: On Mittwoch, 26. Mai 2010, Philipp Kern wrote: ETOPIC. You have to specify the format in the package. The lack of debian/source/format should be a de facto declaration of source format 1.0. Nowhere they write that 1.0 will disappear. And they say in the long term too, so debian/source/format should be propagating naturally into most of the packages due to the lintian tag. And I haven't heard of a single reason, why the lack of debian/source/format *shouldn't* be interpreted as, well, source/format 1.0. As far as I understood it, it's not that much about unpacking, because the format is pretty clear then, but about packing (or in this case repacking) the source package. There you should be explicit in what you mean because future versions of dpkg might abort if the source version is not explicitly specified in the package. Now I think the maintainers did outline why they want that in the past. :P dpkg should not abort - that will cause a FTBFS through no fault of the package. First thing dpkg-buildpackage does is pack up the unpacked source. The archive is regularly rebuilt from the existing source packages; dpkg must not change the behaviour in a way that breaks such rebuilds. Let's not get into making that a special case, there are lots of situations where third parties need to rebuild packages outside Debian and there can be no justification for making such rebuilds impossible merely for the convenience of dpkg. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpTysZGamMNu.pgp Description: PGP signature
Re: Recent changes in dpkg
On 2010-05-27, Neil Williams codeh...@debian.org wrote: No, it doesn't. It is now but at some point there won't be any default, meaning that if you don't have debian/source/format, dpkg will error out. Nothing wrong with that. If, eventually, dpkg fails with an error when debian/source/format does not exist, dpkg is causing the package to FTBFS and therefore dpkg is causing an unnecessary upload due to the changed behaviour of dpkg. There is A LOT wrong with that. People, calm down. It's failed to build from source, which implies there is a source package already. It won't fail on unpack to cause FTBFS, it might fail when preparing the source upload. From the infrastructure side I'm ok with that, TBH. (Iff there are valid reasons for it, that is. But I guess we already determined that automatic detection of various things isn't always the best choice. Making 1.0 non-native and 1.0 native explicit wouldn't sound too wrong. :P) Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnhvs6e3.kdb.tr...@kelgar.0x539.de
Re: Recent changes in dpkg
On Thu, May 27, 2010 at 07:54:03AM +0100, Neil Williams wrote: On Wed, 26 May 2010 23:44:52 +0200 Iustin Pop iu...@k1024.org wrote: There is nothing wrong with a source package that glides through several stable releases without needing a rebuild, especially if it only builds an Arch:all binary package. As long as it is bug free, an ancient standards version alone is not sufficient reason to change anything in the package or make any upload just for the sake of making an upload. But here I disagree. A couple of stable releases is, let's say, 4 years? In the last four years, there have been significant changes (advancements?) in the state of Debian packaging. As such, most, if not all, nontrivial packages would be improved if they're brought up to date. I can think of a few perl modules that won't need another upload until Perl6 is not only released but sufficiently stable that Perl5 is to be removed. That doesn't look like it will happen within a couple of stable releases, if at all. (It will take us longer to transition from Perl5 than it did for libgtk1.2 and that took more than two stable releases.) Other packages affected could be data packages etc. Data packages are a good point, to which I reply: how will they take advantages of new compression formats? After Squeeze is released, I'll have half a dozen or more packages that will be the same version in oldstable through to unstable and none of those currently have any bugs or lintian warnings other than an old/ancient standards version or similarly minor issues. None of those would give any benefits *to users* by being updated with respect to the packaging. To users? Probably not. But to fellow developers? Do those packages already have Vcs-* fields so that I can retrieve them easily with debcheckout? Do the patches already come in DEP-3 format, so that tracking where they originate is easy for automated tools? I agree that we don't *have* to update the packages. All I'm saying, to me it seems that the world of packaging standards is not sitting, and not doing an update once per release seems a bit (just a bit) strange to me. But I understand your point, and I'm not saying it is a wrong point. Just trying to express why I believe doing a rebuild per release helps more than hurts. regards, iustin signature.asc Description: Digital signature
Re: Recent changes in dpkg
Neil, am Thu, May 27, 2010 at 08:04:25AM +0100 hast du folgendes geschrieben: dpkg should not abort - that will cause a FTBFS through no fault of the package. First thing dpkg-buildpackage does is pack up the unpacked source. no, it does not for '-B', which is what our infrastructure uses. Even when we build arch:all also this doesn't repack the source package neither, which is what I wanted to say with my last mail. Ciao Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527072735.gb21...@kelgar.0x539.de
Re: Recent changes in dpkg
On Thu, 27 May 2010 09:12:24 +0200 Iustin Pop iu...@k1024.org wrote: Data packages are a good point, to which I reply: how will they take advantages of new compression formats? No need - just because these are data packages doesn't mean they are even tens of kilobytes in size. These are source packages, not data binary packages split out from other compiled binaries. A new compression format won't save more than a few bytes on a small data package - why bother? We cannot restrict ourselves to only the .deb files in Debian. There are plenty of situations where the .deb format is used to package a specific configuration tweak or a little snippet of data. In many cases, the contents vary slightly across lots of different use cases, so the source builds dozens of tiny data packages and the devices pick and choose which configurations to support. Think along the lines of xorg-xserver-video-* where you don't want -all, you want specific devices to cherry-pick only the drivers that are needed for that specific chipset. The packages themselves are tiny but there are a LOT of them. You don't want to rebuild and reupload dozens and dozens merely to add debian/source/format to every single one. You also cannot allow every device to install every variant, even if you remove most later, because of all the unwanted dependencies. After Squeeze is released, I'll have half a dozen or more packages that will be the same version in oldstable through to unstable and none of those currently have any bugs or lintian warnings other than an old/ancient standards version or similarly minor issues. None of those would give any benefits *to users* by being updated with respect to the packaging. To users? Probably not. But to fellow developers? Do those packages already have Vcs-* fields so that I can retrieve them easily with debcheckout? Do the patches already come in DEP-3 format, so that tracking where they originate is easy for automated tools? Some have no VCS - they are downloaded from CPAN or are my own upstream, I have the debian/ directory on my own systems and that's all that's needed. There are no patches (especially when I am upstream). There really are packages out there which are so simple and trivial to package that the enhancements in Debian packaging methods since Etch have no benefit to anyone, including other DD's. Again, this is also applicable to uses of .deb outside Debian where thinks like VCS- and DEP3 are meaningless, even lintian is ignored. Emdebian automatically drops all VCS- fields, indeed all debian/control fields which are absolutely mandatory to get the package accepted into a random reprepro archive. We cannot go around assuming that everyone using dpkg is only using it within the confines of Debian Policy, let alone Debian Best Practice. Why do we assume that every package should automatically use the latest whizz-bang-feature merely because that feature exists? Some packages do not need a VCS of any kind and some never need patches or even debhelper 5. .deb is a useful format in it's own right - Debian should not make changes that undermine the usefulness of .deb outside Debian, if only because it undermines the maintenance of some packages within Debian where packaging life really is that simple. I agree that we don't *have* to update the packages. All I'm saying, to me it seems that the world of packaging standards is not sitting, and not doing an update once per release seems a bit (just a bit) strange to me. Not to me. One release to last from oldstable to unstable is actually very appealing, for packages where life is sufficiently simple. One day, I might even get a package where it gets into oldstable at the very first upload. But I understand your point, and I'm not saying it is a wrong point. Just trying to express why I believe doing a rebuild per release helps more than hurts. I think you're seeing complexity where none exists. I have some very simple packages and I like them like that. :-) Changing the packaging merely because the maintainer is bored of using debhelper 5 etc. is just sad. (I remember someone in the Debian release team - at the time, no names but he knows who he is - saying that DD's should consider every upload to unstable to be the version that will get into stable.) -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpDQ0ZaBmpag.pgp Description: PGP signature
Re: Recent changes in dpkg
Hi, On Wed, 26 May 2010, Bernd Zeimetz wrote: * dpkg-dev provides a new script called dpkg-buildflags that packages should use in debian/rules to retrieve the default value of various compilation flags. Bug #578597[1] has been submitted against debian-policy. When generalized this offer us centralized archive-wide control of the default build flags as well as the possibility for end-users to try out easily new flags. So you plan to enforce something which resulted in a lot of FTBFS due to the fact that buildflags, which were written into a Makefile by configure or similar tools, were overridden by the default values from dpkg again as they were still present in the environment? I'm sorry I don't understand you. When Frank merged the initial change from Ubuntu it created lot of concerns that dpkg-buildpackage was not the right place to set such default values because calling debian/rules directly would not have them. For various reasons the discussion stalled and it's only way later that I restarted the discussion to find a solution that suits everybody. Following that discussion, we decided to build this new interface that packages must explicitly call (much like they call dpkg-architecture) to retrieve the default values. Until most packages have been converted to use this new interface, dpkg-buildpackage will continue to export the environment variables but it gets the values exported ouf of dpkg-buildflags. * The plan concerning dpkg-source and the default source format has been clarified. In the long term, the default format will disappear and debian/source/format will become mandatory. The lintian tag missing-debian-source-format[2] will help us track that. Which will force developers to touch most of the packages in the archive just to realize this? Sorry, but that's insane. You should not try to force people into migrating to some new format because *you* think it is better. This is not a decision which should be decided by the dpkg maintainers - instead it needs to be discussed within the developers and maintainers. While the new format Yeah! You managed to start yet another useless thread on the topic. My sole response will be this one. Yes, we're starting a long-term migration that will require every package to be modified. The reasons are that the dpkg maintainers consider the format 1.0 to no longer be a desirable default for dpkg-source given the availability of improved formats. We also acknowledge the fact that there's no longer a single format that suits all cases and as such we want the maintainer to be explicit about the choice they make. No, we won't break packages, it's a migration and dpkg-source will be switched only when all packages have been modified. There are warnings in place both in dpkg-source and in lintian. We are fully aware that it will take very long and README.feature-removal-schedule of dpkg says this: What: fallback of dpkg-source to source format 1.0 without explicit debian/source/format Status: deprecated When: 1.17.x Warning: program and lintian (missing-debian-source-format) Why: With the support of multiple source formats, the user should be explicit about the desired source format. The fallback to 1.0 is there only for backwards compatiblity but will be removed once all packages have the debian/source/format file. This is unlikely to happen before 1.17.x. And 1.17.x means squeeze+2. And at that time, 1.0 will still be supported, it's just that it won't be assumed if debian/source/format is absent. provides some advantages when it comes to the handling of patches, the 1.0 format is still much more flexible to use - for example it does not require an existing tarball to build a package, which is very useful for testing. Testing requires binary packages only. Use dpkg-buildpackage -b and it will work even without any upstream tarball. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527080551.gd11...@rivendell
Re: Recent changes in dpkg
On 05/26/2010 11:07 PM, Ben Hutchings wrote:
Environment variables do not override variable definitions in a makefile.
You can't believe how messy upstream stuff can be. Messing with $(LDFLAGS) and
$${LDFLAGS} and simmilar stuff just happens
--
Bernd ZeimetzDebian GNU/Linux Developer
http://bzed.dehttp://www.debian.org
GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bfe3965.4020...@bzed.de
Re: Recent changes in dpkg
Hi! * Philipp Kern tr...@philkern.de [2010-05-27 08:11:36 CEST]: | As far as I understood it, it's not that much about unpacking, because | the format is pretty clear then, but about packing (or in this case | repacking) the source package. There you should be explicit in what | you mean because future versions of dpkg might abort if the source version | is not explicitly specified in the package. Why is that needed? It always was explicit that 1.0 is meant, what's the need for the change? | Now I think the maintainers did outline why they want that in the past. :P Why they want it unfortunately is a wrong reasoning - the actual pending and still unanswered question is why it is needed. They want people to switch to 3.0. By forcing to put something into debian/source/format people start putting 1.0 in there for no gain. I still fail to have received any real answer why debian/source/format 1.0 containing is better than no debian/source directory at all. Making it mandatory does break existing behavior, even though I was told that it won't happen before all packages do have it. Fortunately, there isn't only packages in our pool, so that point will never be reached, and forcing people to put it in there out of principle with no actual outlined reason on *why* doesn't help. Thanks, Rhonda -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527092602.ga28...@anguilla.debian.or.at
Re: Recent changes in dpkg
* Philipp Kern tr...@philkern.de [2010-05-27 09:05:39 CEST]: But I guess we already determined that automatic detection of various things isn't always the best choice. Making 1.0 non-native and 1.0 native explicit wouldn't sound too wrong. :P) Unfortunately, dpkg doesn't support that - thus adding debian/source/format 1.0 is no gain at all over leaving the file out completely. Making the file mandatory thus doesn't gain anything, at all. Thanks, Rhonda -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527093513.ga1...@anguilla.debian.or.at
Re: Recent changes in dpkg
Hi! * Raphael Hertzog hert...@debian.org [2010-05-27 10:05:51 CEST]: Yes, we're starting a long-term migration that will require every package to be modified. The reasons are that the dpkg maintainers consider the format 1.0 to no longer be a desirable default for dpkg-source given the availability of improved formats. We also acknowledge the fact that there's no longer a single format that suits all cases and as such we want the maintainer to be explicit about the choice they make. Requiring the file won't get rid of format 1.0 but will make people put 1.0 into debian/source/format. Planing to make the file mandatory might indeed make more people think about it, though having the file won't make the format 1.0 go away. There are already quite some packages in the pool which explicitly have put 1.0 into the file - thus stating that your approach to deprecate 1.0 with making the file mandatory is on the losing end. So what is the real goal of making the file mandatory, your above stated reason is unfortunately not working out? No, we won't break packages, it's a migration and dpkg-source will be switched only when all packages have been modified. What do you include in the set of all packages? All packages in the Debian pool? All packages that derivates might have? All packages that commercial software developers offer? You are hopefully very well aware that Debian isn't the only distribution or development body that uses the .deb format. And 1.17.x means squeeze+2. And at that time, 1.0 will still be supported, it's just that it won't be assumed if debian/source/format is absent. And again, explicitly, I would like to know what the real benefit of this change is that would *then* break building source packages, when 1.0 itself isn't planned to get deprecated. Thanks, Rhonda -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527094702.gb1...@anguilla.debian.or.at
Re: Recent changes in dpkg
On Thu, May 27, 2010 at 11:26:02AM +0200, Gerfried Fuchs wrote: Hi! * Philipp Kern tr...@philkern.de [2010-05-27 08:11:36 CEST]: | As far as I understood it, it's not that much about unpacking, because | the format is pretty clear then, but about packing (or in this case | repacking) the source package. There you should be explicit in what | you mean because future versions of dpkg might abort if the source version | is not explicitly specified in the package. Why is that needed? It always was explicit that 1.0 is meant, what's the need for the change? | Now I think the maintainers did outline why they want that in the past. :P Why they want it unfortunately is a wrong reasoning - the actual pending and still unanswered question is why it is needed. They want people to switch to 3.0. By forcing to put something into debian/source/format people start putting 1.0 in there for no gain. I still fail to have received any real answer why debian/source/format 1.0 containing is better than no debian/source directory at all. There is one possible benefit: impossibility to create a native package when the .orig.tar.gz is missing, which happens much too often. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527100047.ga4...@glandium.org
Re: Recent changes in dpkg
On Donnerstag, 27. Mai 2010, Mike Hommey wrote: There is one possible benefit: impossibility to create a native package when the .orig.tar.gz is missing, which happens much too often. in my world (which doesnt consist entirely out of Debian main on ftp.debian.org) this is a regression. signature.asc Description: This is a digitally signed message part.
Re: Recent changes in dpkg
On Thu, May 27, 2010 at 12:00:47PM +0200, Mike Hommey wrote: Why they want it unfortunately is a wrong reasoning - the actual pending and still unanswered question is why it is needed. They want people to switch to 3.0. By forcing to put something into debian/source/format people start putting 1.0 in there for no gain. I still fail to have received any real answer why debian/source/format 1.0 containing is better than no debian/source directory at all. There is one possible benefit: impossibility to create a native package when the .orig.tar.gz is missing, which happens much too often. Now you need to be more verbose. The dpkg-source manpage still lists 1.0 as supporting both patched and native. Bastian -- Either one of us, by himself, is expendable. Both of us are not. -- Kirk, The Devil in the Dark, stardate 3196.1 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527102740.ga26...@wavehammer.waldi.eu.org
Re: Recent changes in dpkg
On Thu, 27 May 2010, Gerfried Fuchs wrote: * Philipp Kern tr...@philkern.de [2010-05-27 09:05:39 CEST]: But I guess we already determined that automatic detection of various things isn't always the best choice. Making 1.0 non-native and 1.0 native explicit wouldn't sound too wrong. :P) Unfortunately, dpkg doesn't support that - thus adding debian/source/format 1.0 is no gain at all over leaving the file out completely. I would accept patches implementing this. But from my point of view, 1.0 is to be avoided so I don't see the need to implement this. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527103152.gb...@rivendell
Re: Recent changes in dpkg
On Thu, May 27, 2010 at 12:27:40PM +0200, Bastian Blank wrote: On Thu, May 27, 2010 at 12:00:47PM +0200, Mike Hommey wrote: Why they want it unfortunately is a wrong reasoning - the actual pending and still unanswered question is why it is needed. They want people to switch to 3.0. By forcing to put something into debian/source/format people start putting 1.0 in there for no gain. I still fail to have received any real answer why debian/source/format 1.0 containing is better than no debian/source directory at all. There is one possible benefit: impossibility to create a native package when the .orig.tar.gz is missing, which happens much too often. Now you need to be more verbose. The dpkg-source manpage still lists 1.0 as supporting both patched and native. Let's replace possible with hypothetical, then. That's the only benefit i can find. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527103541.ga4...@glandium.org
Re: Recent changes in dpkg
On Thu, May 27, 2010 at 12:00:47PM +0200, Mike Hommey wrote: On Thu, May 27, 2010 at 11:26:02AM +0200, Gerfried Fuchs wrote: Hi! * Philipp Kern tr...@philkern.de [2010-05-27 08:11:36 CEST]: | As far as I understood it, it's not that much about unpacking, because | the format is pretty clear then, but about packing (or in this case | repacking) the source package. There you should be explicit in what | you mean because future versions of dpkg might abort if the source version | is not explicitly specified in the package. Why is that needed? It always was explicit that 1.0 is meant, what's the need for the change? | Now I think the maintainers did outline why they want that in the past. :P Why they want it unfortunately is a wrong reasoning - the actual pending and still unanswered question is why it is needed. They want people to switch to 3.0. By forcing to put something into debian/source/format people start putting 1.0 in there for no gain. I still fail to have received any real answer why debian/source/format 1.0 containing is better than no debian/source directory at all. There is one possible benefit: impossibility to create a native package when the .orig.tar.gz is missing, which happens much too often. Hrm, I was under the impression that native packages with an existing source/format of 1.0 would still be allowed? Maybe people could live with the change that 1.0 native packages need to explain themselves as 1.0 (native) in debian/source/format (if that file is present, otherwise assume 1.0 as before, but that's a side issue), or dpkg-source would fail. Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527104829.ge1...@nighthawk.chemicalconnection.dyndns.org
Re: Recent changes in dpkg
]] Neil Williams | You seem to think that every package is going to be uploaded just for | the sake of an upload. | | There is no way to guarantee that ALL packages in Debian will be | uploaded again by some point in the future. | | If a package does not need an upload - e.g. the only issue is an | ancient standards version - then dpkg cannot change behaviour in a way | that makes that package FTBFS. You make it sound like a package upload is a big deal. Sometimes, you upload for small things, there's nothing wrong with that. [...] | If, eventually, dpkg fails with an error when debian/source/format | does not exist, dpkg is causing the package to FTBFS and therefore | dpkg is causing an unnecessary upload due to the changed behaviour of | dpkg. There is A LOT wrong with that. How is this different to other changes in the toolchain which sometimes deprecate and remove functionality which then makes packages FTBFS? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sk5djyiu@qurzaw.linpro.no
Re: Recent changes in dpkg
* Mike Hommey [2010-05-27 12:00 +0200]: There is one possible benefit: impossibility to create a native package when the .orig.tar.gz is missing, which happens much too often. Doesn't look like it's impossible: | dpkg-source: info: source format `3.0 (quilt)' discarded: no orig.tar file found | dpkg-source: info: using source format `1.0' Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527134440.ga28...@foghorn.stateful.de
Re: Recent changes in dpkg
* Carsten Hey cars...@debian.org [2010-05-27 15:44 +0200]: * Mike Hommey [2010-05-27 12:00 +0200]: There is one possible benefit: impossibility to create a native package when the .orig.tar.gz is missing, which happens much too often. Doesn't look like it's impossible: | dpkg-source: info: source format `3.0 (quilt)' discarded: no orig.tar file found | dpkg-source: info: using source format `1.0' You're right if a newer dpkg is used: | dpkg-source: error: can't build with source format '3.0 (quilt)': no orig.tar file found Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527134738.gb8...@foghorn.stateful.de
Re: Recent changes in dpkg
On Thu, May 27, 2010 at 03:44:40PM +0200, Carsten Hey wrote: * Mike Hommey [2010-05-27 12:00 +0200]: There is one possible benefit: impossibility to create a native package when the .orig.tar.gz is missing, which happens much too often. Doesn't look like it's impossible: | dpkg-source: info: source format `3.0 (quilt)' discarded: no orig.tar file found | dpkg-source: info: using source format `1.0' That's supposed to have been fixed. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527134741.ga13...@glandium.org
Re: Recent changes in dpkg
* Gerfried Fuchs rho...@deb.at [100527 11:47]: Requiring the file won't get rid of format 1.0 but will make people put 1.0 into debian/source/format. Planing to make the file mandatory might indeed make more people think about it, though having the file won't make the format 1.0 go away. There are already quite some packages in the pool which explicitly have put 1.0 into the file - thus stating that your approach to deprecate 1.0 with making the file mandatory is on the losing end. So what is the real goal of making the file mandatory, your above stated reason is unfortunately not working out? Not ignoring errors is an important part of software quality. There are mostly three possibilities: 1) not require the file but work properly without - not possible as there are many packages that still need 1.0 and changing the default to 3.0 would annony developers not liking it too much. 2) not require the file but choose old format in that case - in case of error people silently get the old deficit format 2) require the file in the long run - everyone can chose their own, noone will get an old deficit format without requesting it in the future, noone will get the new format without requesting it. Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527143747.ga1...@pcpool00.mathematik.uni-freiburg.de
Re: Recent changes in dpkg
[Gerfried Fuchs] Requiring the file won't get rid of format 1.0 but will make people put 1.0 into debian/source/format. Planing to make the file mandatory might indeed make more people think about it, though having the file won't make the format 1.0 go away. It's pretty clear that this is social engineering. The dpkg maintainers want to force every package maintainer to _think_ about which source format they wish to use. To ensure that, in the long run, you no longer have the choice to simply ignore the format war. I am puzzled by one thing, however. The dpkg maintainers chose not to add tar.bz2 support to format 1.0 (the only real advantage many of us can see to format 3.0) on the grounds that it would change the format, and thus format 1.0 would effectively become format 1.1 or something. Which, for a deprecated format, was too much effort. ...And here we are now, talking about an incompatible change to format 1.0. Yay? So _now_ can we get tar.bz2 format support in there, while we're at it? Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527183829.gd18...@p12n.org
Re: Recent changes in dpkg
On Thu, May 27, 2010 at 02:54:17PM +0200, Tollef Fog Heen wrote: ]] Neil Williams | You seem to think that every package is going to be uploaded just for | the sake of an upload. | There is no way to guarantee that ALL packages in Debian will be | uploaded again by some point in the future. | If a package does not need an upload - e.g. the only issue is an | ancient standards version - then dpkg cannot change behaviour in a way | that makes that package FTBFS. You make it sound like a package upload is a big deal. Sometimes, you upload for small things, there's nothing wrong with that. No, he's saying that 16,000 package uploads are a big deal, which is the number of source packages that have to be uploaded in order to complete this transition. I understand better Raphaël's position after the last thread - that a source package is a .dsc + related files, not an unpacked tree, so refusing to create a 1.0 source package out of an unpacked tree isn't a redefinition of the format. Even so, transitions that require sourceful changes to every single package in the archive are a bad idea, and almost always translate as busywork. | If, eventually, dpkg fails with an error when debian/source/format | does not exist, dpkg is causing the package to FTBFS and therefore | dpkg is causing an unnecessary upload due to the changed behaviour of | dpkg. There is A LOT wrong with that. How is this different to other changes in the toolchain which sometimes deprecate and remove functionality which then makes packages FTBFS? Can you point to such a toolchain change that required changes to even 20% of the packages in th archive? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527185530.ga5...@dario.dodds.net
Re: Recent changes in dpkg
]] Steve Langasek | On Thu, May 27, 2010 at 02:54:17PM +0200, Tollef Fog Heen wrote: | ]] Neil Williams | | | You seem to think that every package is going to be uploaded just for | | the sake of an upload. | | | There is no way to guarantee that ALL packages in Debian will be | | uploaded again by some point in the future. | | | If a package does not need an upload - e.g. the only issue is an | | ancient standards version - then dpkg cannot change behaviour in a way | | that makes that package FTBFS. | | You make it sound like a package upload is a big deal. Sometimes, you | upload for small things, there's nothing wrong with that. | | No, he's saying that 16,000 package uploads are a big deal, which is the | number of source packages that have to be uploaded in order to complete this | transition. (There are about 12.3k 1.0 packages, not 16k, but that's a fairly minor detail. :-) How many of those would have been uploaded anyway over two cycles? I don't have firm numbers, but my suspicion is «most of them». This would then just be one of those minor things you do when you update to a newer standards-version and fix various lintian nits. In fact, according to http://upsilon.cc/~zack/stuff/dpkg-v3/, we're looking at about 480 packages being converted to 3.0 per month, meaning that at the current rate we'll probably be at something like 120% of the archive converted for squeeze+1. ;-) [...] | How is this different to other changes in the toolchain which sometimes | deprecate and remove functionality which then makes packages FTBFS? | | Can you point to such a toolchain change that required changes to even 20% | of the packages in th archive? I wasn't around for the libc5 = libc6 transition, but my understanding is it was larger than 20% of the archive. I would guesstimate the removal of /usr/X11R6 at being around the 20% mark (including binNMUs and all). So while they're uncommon, they're not unheard of. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4qpdui7@qurzaw.linpro.no
Re: Recent changes in dpkg
Bernhard R. Link wrote: There are mostly three possibilities: 2) not require the file but choose old format in that case - in case of error people silently get the old deficit format That problem can easily be avoided by adding deprecation warnings. Debhelper does this for packages that don't specify a compatability level and get the bad old v1 level by default. So I don't think that is a serious problem. -- see shy jo signature.asc Description: Digital signature
Re: Recent changes in dpkg
On 27/05/2010 21:17, Tollef Fog Heen wrote: I wasn't around for the libc5 = libc6 transition, but my understanding is it was larger than 20% of the archive. I would guesstimate the removal of /usr/X11R6 at being around the 20% mark (including binNMUs and all). So while they're uncommon, they're not unheard of. There is also the /usr/doc = /usr/share/doc transition. -- Jean-Christophe Dubacq -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bfec9b1.7080...@free.fr
Re: Recent changes in dpkg
Peter Samuelson wrote: It's pretty clear that this is social engineering. The dpkg maintainers want to force every package maintainer to _think_ about which source format they wish to use. To ensure that, in the long run, you no longer have the choice to simply ignore the format war. I wonder if anything can be learned from debhelper's history of compatability levels. numpkgs compat levelintroduced deprecated 1 8 Jun 2010 6625 7 Apr 2008 675 6 Jan 2008 5398 5 Nov 2005 1638 4 Apr 2002Mar 2009 156 3 Feb 2001Nov 2005 25 2 Jul 2000Jun 2005 25 1 Sep 1997Jun 2005 557 unknown[1] Sep 1997Jun 2005 [1] No debian/compat or DH_COMPAT currently means compat level 1 is used. A few hundred of these packages do not use debhelper at all; I don't have the exact number handy. Some points I'd draw from this data and what I remember about how the numbers used to look: * About 50% of packages switched to the newest version in just a couple of years, without me being too annoying with deprecation messages, or making any changes that forced the switch. * Deprecation warnings seem to do a good job of gradually eroding the number of holdouts after the initial switch rush. (The relatively large number of packages still using v4 is probably because it was the best level for a long period (2002-2005), and only started deprecation warnings a year ago.) * After a certian point, one has to take action to get rid of the last few packages in the long tail. It would be pretty easy at this point for me to get rid of v2 and v3 entirely. But still probably not worth the effort, as it would only remove a few dozen lines of code from debhelper. The time is better spent getting rid of individual deprecated debhelper commands. * At this point, mandating a version number at the cost of breaking a few hundred packages might be worth it, though mostly because it would probably cause half of them to update away from v1. * If I had mandated a version when v2 was introduced, I would have caused many long threads on debian-devel, and would probably now have to contend with a lump of packages using v2 (or yada) instead of the current lump at v1. -- see shy jo signature.asc Description: Digital signature
Re: Recent changes in dpkg
Joey, first of all thanks for the data... :) On 2010-05-27, Joey Hess jo...@debian.org wrote: I wonder if anything can be learned from debhelper's history of compatability levels. numpkgs compat level introduced deprecated 1 8 Jun 2010 You really are from the future, then. ;-) * After a certian point, one has to take action to get rid of the last few packages in the long tail. It would be pretty easy at this point for me to get rid of v2 and v3 entirely. But still probably not worth the effort, as it would only remove a few dozen lines of code from debhelper. The time is better spent getting rid of individual deprecated debhelper commands. But then v2 and v3 support might have bitrotten and FTBFS could have been introduced in the meantime due to the toolchain? Sometimes dropping support for old levels might make sense if almost nobody uses it and wouldn't notice breakage... (Not to say that this applies to debhelper in any way...) Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnhvtmb4.od3.tr...@kelgar.0x539.de
Re: Recent changes in dpkg
On Wed, May 26, 2010 at 10:34:32PM +0100, Neil Williams wrote: On Wed, 26 May 2010 22:59:25 +0200 Iustin Pop iu...@k1024.org wrote: On Wed, May 26, 2010 at 10:43:36PM +0200, Bernd Zeimetz wrote: On 05/24/2010 11:05 AM, Raphael Hertzog wrote: I think the announcement is wrong, we cannot ever expect every single package to be touched for any single change. We don't even do that when libc changes SONAME - that only affects compiled packages, this theoretically affects all source packages which means huge numbers of rebuilds and transitions. There is nothing wrong with a source package that glides through several stable releases without needing a rebuild, especially if it only builds an Arch:all binary package. As long as it is bug free, an ancient standards version alone is not sufficient reason to change anything in the package or make any upload just for the sake of making an upload. So, we are talking about packages that have a) no (fixed) bug reports b) no new upstream version in 4 years. How many packages are we talking about here? Is there a way to get the number of packages that have the same version in Lenny and Squeeze? Anyway, I don't think asking for an upload once every 4 years is so much of a burden. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527204747.ga12...@atlan
Re: Recent changes in dpkg
On Thu, 27 May 2010 10:05:51 +0200, Raphael Hertzog wrote: Yes, we're starting a long-term migration that will require every package to be modified. [..] No, we won't break packages, it's a migration and dpkg-source will be switched only when all packages have been modified. There are warnings in place both in dpkg-source and in lintian. We are fully aware that it will take very long [..] And 1.17.x means squeeze+2. And at that time, 1.0 will still be supported, it's just that it won't be assumed if debian/source/format is absent. Thanks for the clear summary of the plans. FWIW: I think that's a reasonable approach. Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of Free Software Foundation Europe `-NP: Dire Straits: Sultans Of Swing signature.asc Description: Digital signature
Re: Recent changes in dpkg
On Thu, May 27, 2010 at 10:47:47PM +0200, Thomas Weber wrote: How many packages are we talking about here? Is there a way to get the number of packages that have the same version in Lenny and Squeeze? According to a quick query on UDD, there are 3169 source packages which have the same source version in Lenny and Squeeze. 746 when comparing Etch and Squeeze. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org signature.asc Description: Digital signature
Re: Recent changes in dpkg
On 05/24/2010 11:05 AM, Raphael Hertzog wrote: Hello, The versions 1.15.6 and 1.15.7 of dpkg introduced several important changes. Let's skim over them: [...] * dpkg-dev provides a new script called dpkg-buildflags that packages should use in debian/rules to retrieve the default value of various compilation flags. Bug #578597[1] has been submitted against debian-policy. When generalized this offer us centralized archive-wide control of the default build flags as well as the possibility for end-users to try out easily new flags. So you plan to enforce something which resulted in a lot of FTBFS due to the fact that buildflags, which were written into a Makefile by configure or similar tools, were overridden by the default values from dpkg again as they were still present in the environment? * The plan concerning dpkg-source and the default source format has been clarified. In the long term, the default format will disappear and debian/source/format will become mandatory. The lintian tag missing-debian-source-format[2] will help us track that. Which will force developers to touch most of the packages in the archive just to realize this? Sorry, but that's insane. You should not try to force people into migrating to some new format because *you* think it is better. This is not a decision which should be decided by the dpkg maintainers - instead it needs to be discussed within the developers and maintainers. While the new format provides some advantages when it comes to the handling of patches, the 1.0 format is still much more flexible to use - for example it does not require an existing tarball to build a package, which is very useful for testing. You know that there are a lot of arguments against the 3.0 format out there, so please do not enforce such changes without discussing them first. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bfd87f8.90...@bzed.de
Re: Recent changes in dpkg
On 2010-05-26, Bernd Zeimetz be...@bzed.de wrote: * The plan concerning dpkg-source and the default source format has been clarified. In the long term, the default format will disappear and debian/source/format will become mandatory. The lintian tag missing-debian-source-format[2] will help us track that. Which will force developers to touch most of the packages in the archive just to realize this? Sorry, but that's insane. You should not try to force people into migrating to some new format because *you* think it is better. ETOPIC. You have to specify the format in the package. Nowhere they write that 1.0 will disappear. And they say in the long term too, so debian/source/format should be propagating naturally into most of the packages due to the lintian tag. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnhvr2ff.hvt.tr...@kelgar.0x539.de
Re: Recent changes in dpkg
On Wed, May 26, 2010 at 10:43:36PM +0200, Bernd Zeimetz wrote: On 05/24/2010 11:05 AM, Raphael Hertzog wrote: * The plan concerning dpkg-source and the default source format has been clarified. In the long term, the default format will disappear and debian/source/format will become mandatory. The lintian tag missing-debian-source-format[2] will help us track that. Which will force developers to touch most of the packages in the archive just to realize this? Sorry, but that's insane. You should not try to force people into migrating to some new format because *you* think it is better. This is not a decision which should be decided by the dpkg maintainers - instead it needs to be discussed within the developers and maintainers. While the new format provides some advantages when it comes to the handling of patches, the 1.0 format is still much more flexible to use - for example it does not require an existing tarball to build a package, which is very useful for testing. You know that there are a lot of arguments against the 3.0 format out there, so please do not enforce such changes without discussing them first. I think you're misreading the announcement. What will change is that declaring the format (either 1.0 or 3.0 in whatever variant) will be required, not migrating to the new formats. regards, iustin signature.asc Description: Digital signature
Re: Recent changes in dpkg
On Wed, May 26, 2010 at 10:43:36PM +0200, Bernd Zeimetz wrote: On 05/24/2010 11:05 AM, Raphael Hertzog wrote: Hello, The versions 1.15.6 and 1.15.7 of dpkg introduced several important changes. Let's skim over them: [...] * dpkg-dev provides a new script called dpkg-buildflags that packages should use in debian/rules to retrieve the default value of various compilation flags. Bug #578597[1] has been submitted against debian-policy. When generalized this offer us centralized archive-wide control of the default build flags as well as the possibility for end-users to try out easily new flags. So you plan to enforce something which resulted in a lot of FTBFS due to the fact that buildflags, which were written into a Makefile by configure or similar tools, were overridden by the default values from dpkg again as they were still present in the environment? [...] Environment variables do not override variable definitions in a makefile. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526210731.ge5...@decadent.org.uk
Re: Recent changes in dpkg
On Wed, 26 May 2010 22:59:25 +0200 Iustin Pop iu...@k1024.org wrote: On Wed, May 26, 2010 at 10:43:36PM +0200, Bernd Zeimetz wrote: On 05/24/2010 11:05 AM, Raphael Hertzog wrote: * The plan concerning dpkg-source and the default source format has been clarified. In the long term, the default format will disappear and debian/source/format will become mandatory. The lintian tag missing-debian-source-format[2] will help us track that. Which will force developers to touch most of the packages in the archive just to realize this? Sorry, but that's insane. You should not try to force people into migrating to some new format because *you* think it is better. This is not a decision which should be decided by the dpkg maintainers - instead it needs to be discussed within the developers and maintainers. While the new format provides some advantages when it comes to the handling of patches, the 1.0 format is still much more flexible to use - for example it does not require an existing tarball to build a package, which is very useful for testing. You know that there are a lot of arguments against the 3.0 format out there, so please do not enforce such changes without discussing them first. I think you're misreading the announcement. What will change is that declaring the format (either 1.0 or 3.0 in whatever variant) will be required, not migrating to the new formats. Declaring a format mandates touching every single package because the vast majority of packages are currently dpkg source format 1.0 ONLY because debian/source/format does NOT exist. The dpkg maintainers appear to want all packages to have a file that currently only exists in a fraction of packages. We cannot add a file to packages without touching them / rebuilding them, so as the lack of a file is proposed as being *against eventual policy* then Policy is being abused to do what it has been claimed Policy should never do - force a change that is NOT already implemented in most affected packages. The ABSENCE of debian/source/format needs to be explicitly retained as a de facto declaration of dpkg source format 1.0. i.e. unless explicitly specified, 1.0 needs to BE the default. Any other proposal tries to abuse Policy to implement a (trivial) change affecting every single source package in Debian. I find that unacceptable. If dpkg eventually causes FTBFS due to the lack of this file, then dpkg will be buggy, not the package. This is especially true when nothing has changed in the package; the only change would be in dpkg behaviour. has been clarified. In the long term, the default format will disappear and debian/source/format will become mandatory. The I think the announcement is wrong, we cannot ever expect every single package to be touched for any single change. We don't even do that when libc changes SONAME - that only affects compiled packages, this theoretically affects all source packages which means huge numbers of rebuilds and transitions. There is nothing wrong with a source package that glides through several stable releases without needing a rebuild, especially if it only builds an Arch:all binary package. As long as it is bug free, an ancient standards version alone is not sufficient reason to change anything in the package or make any upload just for the sake of making an upload. debian/source/format cannot become mandatory without causing every single source package to be modified. For what? Just to add 6 bytes? -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpvYmN5ux453.pgp Description: PGP signature
Re: Recent changes in dpkg
On Wed, May 26, 2010 at 10:34:32PM +0100, Neil Williams wrote: On Wed, 26 May 2010 22:59:25 +0200 Iustin Pop iu...@k1024.org wrote: On Wed, May 26, 2010 at 10:43:36PM +0200, Bernd Zeimetz wrote: On 05/24/2010 11:05 AM, Raphael Hertzog wrote: * The plan concerning dpkg-source and the default source format has been clarified. In the long term, the default format will disappear and debian/source/format will become mandatory. The lintian tag missing-debian-source-format[2] will help us track that. Which will force developers to touch most of the packages in the archive just to realize this? Sorry, but that's insane. You should not try to force people into migrating to some new format because *you* think it is better. This is not a decision which should be decided by the dpkg maintainers - instead it needs to be discussed within the developers and maintainers. While the new format provides some advantages when it comes to the handling of patches, the 1.0 format is still much more flexible to use - for example it does not require an existing tarball to build a package, which is very useful for testing. You know that there are a lot of arguments against the 3.0 format out there, so please do not enforce such changes without discussing them first. I think you're misreading the announcement. What will change is that declaring the format (either 1.0 or 3.0 in whatever variant) will be required, not migrating to the new formats. Declaring a format mandates touching every single package because the vast majority of packages are currently dpkg source format 1.0 ONLY because debian/source/format does NOT exist. […] I was only responding to Bernd's email which sounded like he misread the change. Whether the actual change is good or not, it's another issue, on which I'm disagreeing (but not very strongly, i.e. I could live with it): I think the announcement is wrong, we cannot ever expect every single package to be touched for any single change. We don't even do that when libc changes SONAME - that only affects compiled packages, this theoretically affects all source packages which means huge numbers of rebuilds and transitions. Agreed. There is nothing wrong with a source package that glides through several stable releases without needing a rebuild, especially if it only builds an Arch:all binary package. As long as it is bug free, an ancient standards version alone is not sufficient reason to change anything in the package or make any upload just for the sake of making an upload. But here I disagree. A couple of stable releases is, let's say, 4 years? In the last four years, there have been significant changes (advancements?) in the state of Debian packaging. As such, most, if not all, nontrivial packages would be improved if they're brought up to date. debian/source/format cannot become mandatory without causing every single source package to be modified. For what? Just to add 6 bytes? Mandatory? I agree it shouldn't be mandatory. I would rather propose a 'W' lintian tag, nothing more, and which will only fire if the last changelog date is after the date this proposal goes live. iustin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526214452.gb2...@teal.hq.k1024.org
Re: Recent changes in dpkg
Hi, On Mittwoch, 26. Mai 2010, Philipp Kern wrote: ETOPIC. You have to specify the format in the package. Nowhere they write that 1.0 will disappear. And they say in the long term too, so debian/source/format should be propagating naturally into most of the packages due to the lintian tag. Yes, I agree. most. But .deb is used in a lot of environments. And I haven't heard of a single reason, why the lack of debian/source/format *shouldn't* be interpreted as, well, source/format = 1.0. cheers, Holger signature.asc Description: This is a digitally signed message part.
