Re: Age of built packages to be part of the jessie release?
2014-11-23 14:27 Stuart Prescott:
Svante Signell wrote:
I wonder how old a package build can be to be part of the release. Some
packages are built up to a year ago, and rebuilding them now FTBFS.
As others have noted already, there are period archive rebuilds to check
what would now ftbfs.
Slightly orthogonal to your question, "up to a year ago" doesn't come close,
actually... 42% of source packages in jessie were uploaded over a year ago,
25% over two years ago, 15% over three years ago, 9% over four years ago.
Fun fact: there are 64 source packages in jessie that are over 10 years old.
Age of source packages in each release:
http://ircbots.debian.net/stats/package_ages.png
(note: this is based on source package uploads; binNMUs not included)
Not nicely backed with hard data as you have here, but from my random
observations looking at the state of many packages over many years (in BSPs,
architecture bootstrapping, etc), I reached similar conclusions.
Would it make sense to trigger rebuilds (or binNMUs, or actions to the same
effect) for all packages in a given architecture when there are important
changes in the toolchain, e.g. the default GCC bumps to a new major version [1]?
For me it makes a lot of sense to have most of the archive rebuilt at that time,
and these newly compiled packages migrated at some point to testing to be
present in the next release.
With the current method it seems that we only check if it FTBFS, and packages
only get recompiled if there are new uploads or binNMUs. But actually
recompiling and moving it to the archive will reveal changes in runtime
behaviour, and thus bugs might be caught/reported/hopefully-fixed sooner. In
some occasions there might even be some bugs fixed (if the compiler of years ago
was buggy) or performance improvements.
I do not know if there are significant drawbacks, for example if it would be
very taxing to have everything built in a short period of time (especially for
less powerful architectures) -- not only for hardware, but delays to other
packages who are uploaded at the same time. Or if there are other fundamental
problems that I did not consider.
In summary, if there's a cheap (esp. in humanpower) way to achieve this, I think
that it would be worth doing it.
[1] Packages depending on other language compilers/interpreters will have
different needs and methods to approach them.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>
Reply to: