[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 <iusty@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

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.


Attachment: signature.asc
Description: Digital signature

Reply to: