Hi!
I noticed this nice behavior from the backports infrastructure: an old
version of a package is only removed if its built on at least the same
architectures than the old one. In an ideal world this is a really nice
and helpful approach to push changes sooner to the users.
Though, we don't live in a real world. There are various problems with
some build hosts, might it be outages, lazy admins not signing the build
files, whatever. I don't want to blame any buildd admin here, it's a
voluntary job and there might always be other things that are more
important.
But, the current situation is that we have for quite a lot packages at
least three different versions in the pool: for firefox, for wesnoth,
for the linux kernel 2.6 it's even _4_ different versions lying around
in the pool.
I consider this a really unconvenient situation. Some might say, 19G
currently aren't that big of a problem, but I consider this also as a
disservice to the users because they might think that some of this
architectures are still supported where technically they aren't really.
How about a deadline of let's say 4 weeks or so at a maximum for any
architecture to catch up with the build of a specific package, and if it
wasn't able to do so remove the old version of that specific package?
There is no need to remove the whole architecture -- thought if it is a
real problem there it will purge itself over the time anyway.
Any thoughts? I hope I don't step on anyone's toes with this
suggestion, I think it's the reasonable thing to do.
Thanks.
Alfie
--
(o)_ ,---ooO--00--Ooo---. FAQ for at.linux: http://alfie.ist.org/LinuxFAQ/
(>)_ ,' Gerfried Fuchs `. GPG-Pub-Key: http://alfie.ist.org/key-alfie.asc
,' <alfie@ist.org> `. GPG-Fingerprint: 3A53 DA5E 797E 9168 351F
`- http://alfie.ist.org/ --' 1024D/EC152942 6666 314F 7A95 EC15 2942
Attachment:
signature.asc
Description: Digital signature