[arch-dev-public] [IDEA] no packages older than one year in repos
Hi, This is an idea I have been thinking about for a while. One disadvantage of rolling release (at least with how we implement it), is that some packages do not get rebuilt in a long time. That can mean policy changes never get fully implemented (e.g. removal of .FILELIST from packages, moving man pages to /usr/share/man, LDFLAGS changes, arch=any, etc). Also, new toolchains bring new optimizations that are good to have. I would like to propose that we ensure no package in the repos goes unbuilt for more than a year. Looking at the current state of the repos, this should not be too much of a hassle once we catch up. There are about 12 packages in [core] and 120 packages in [extra] that currently have not been rebuild for more than a year. So, that indicates new packages to be rebuilt would occur at a rate of about two a week. If people like this idea, I can add the packages to the unimportant rebuild list wiki page (http://wiki.archlinux.org/index.php/DeveloperWiki:Unimportant_Rebuild_List) and gradually start doing to rebuilds. Once caught up, we can add a check to the integrity check script to catch new builds. Allan
2010/2/20, Allan McRae <allan@archlinux.org>:
If people like this idea, I can add the packages to the unimportant rebuild list wiki page (http://wiki.archlinux.org/index.php/DeveloperWiki:Unimportant_Rebuild_List) and gradually start doing to rebuilds. Once caught up, we can add a check to the integrity check script to catch new builds.
I like this idea. -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it
Am 20.02.2010 14:05, schrieb Allan McRae:
Hi,
This is an idea I have been thinking about for a while. One disadvantage of rolling release (at least with how we implement it), is that some packages do not get rebuilt in a long time. That can mean policy changes never get fully implemented (e.g. removal of .FILELIST from packages, moving man pages to /usr/share/man, LDFLAGS changes, arch=any, etc). Also, new toolchains bring new optimizations that are good to have.
I would like to propose that we ensure no package in the repos goes unbuilt for more than a year. Looking at the current state of the repos, this should not be too much of a hassle once we catch up. There are about 12 packages in [core] and 120 packages in [extra] that currently have not been rebuild for more than a year. So, that indicates new packages to be rebuilt would occur at a rate of about two a week.
I like it, if we get archweb support for being notified on such occasions.
On Sat, Feb 20, 2010 at 7:28 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 20.02.2010 14:05, schrieb Allan McRae:
Hi,
This is an idea I have been thinking about for a while. One disadvantage of rolling release (at least with how we implement it), is that some packages do not get rebuilt in a long time. That can mean policy changes never get fully implemented (e.g. removal of .FILELIST from packages, moving man pages to /usr/share/man, LDFLAGS changes, arch=any, etc). Also, new toolchains bring new optimizations that are good to have.
I would like to propose that we ensure no package in the repos goes unbuilt for more than a year. Looking at the current state of the repos, this should not be too much of a hassle once we catch up. There are about 12 packages in [core] and 120 packages in [extra] that currently have not been rebuild for more than a year. So, that indicates new packages to be rebuilt would occur at a rate of about two a week.
I like it, if we get archweb support for being notified on such occasions.
I'm going to add build date as a field to archweb soon enough, so this will be quite easy to query and get a list of relevant packages once that is done. -Dan
a slightly modified approach with some pros (no unnecessary rebuilds) and some cons (more administration overhead): - keep track of dates of all policy changes in a textfile/database. or just the date of the latest policy change. - rebuild packages if they are not rebuilt for $foo time and there has been a policy change since the last rebuild. you could also make $foo different depending on the gravity of the last policy change. Dieter
On 21/02/10 01:00, Dieter Plaetinck wrote:
a slightly modified approach with some pros (no unnecessary rebuilds)
I think you missed the part about it being good to rebuild things with the newer toolchain. So any binary package is worth rebuilding. I suppose arch=any packages could be skipped.
and some cons (more administration overhead):
Any administration overhead is needed to be avoided as it is likely that such things block progress. At the moment, it is easy to just sort the repos by last updated on the package search page and do some rebuilds if you have got some time. If we decide that this would be a goal to have, they can easily be added to the Unimportant Rebuild List page.
On Sun, 21 Feb 2010 17:40:19 +1000 Allan McRae <allan@archlinux.org> wrote:
On 21/02/10 01:00, Dieter Plaetinck wrote:
a slightly modified approach with some pros (no unnecessary rebuilds)
I think you missed the part about it being good to rebuild things with the newer toolchain. So any binary package is worth rebuilding. I suppose arch=any packages could be skipped.
i should have been more clear. I didn't mean to just track all/the latest policy change, but anything worth rebuilding packages for (after a while). So a newer toolchain is one of those things. so with the administrational overhead of keeping track of the latest policy change/toolchain update/... you could prevent packages being rebuilt when not necessary. of course, if such policy change/toolchain update/... happens frequently anyway (at least once a year) my approach doesn't offer much advantages. (unless when you want to say "all packages should be rebuilt in x months from now" for a specific policychange/toolchain update/.. I'm not a packager, so do what you think is best. Dieter
Am Samstag, 20. Februar 2010 14:05:21 schrieb Allan McRae:
I would like to propose that we ensure no package in the repos goes unbuilt for more than a year.
This could be even combined with a more regular repo cleanup. There is quite a chance that among those packages are orphans or unused packages. By this we also ensure that our packages actually build with our current toolchain. -- Pierre Schmitz, https://users.archlinux.de/~pierre
participants (6)
-
Allan McRae
-
Dan McGee
-
Dieter Plaetinck
-
Giovanni Scafora
-
Pierre Schmitz
-
Thomas Bächler