Hello, I've just had a discussion about removing old ebuilds from portage. This is imho the wrong way. This is like destroying already done work. It's a lot easier to update an existing ebuild than writing such an ebuild from the ground up new. So I would prefer to mark old ebuilds with existing bugs as old (e.g. #x86) and mark unmaintened ebuilds e.g. as *x86. Just removing old or unmaintened ebuilds is imho the wrong way. Regards, Alexander
Another solution would be to move old, buggy or unmaintained ebuilds into separate directories in the portage (e.g. /usr/portage/old/net-misc/* .../portage/unmaintained/...), excluding them from normal rsyncs.
Grab them from the Attic if you need them. -> ViewCVS
Nice, so I should do wget *unknown_url* | ebuild merge? Think at those production systems where every ebuild needs to be tested before installing and who aren't updated daily. If you want to clone such a system you need old ebuilds. Or what's with security bugs on systems running old ebuilds? If those ebuilds aren't in portage nobody knows which versions could be vunerable by critical bugs, because nobody knows which versions where sometimes in portage. I could find many more reasons not to delete old versions completely from portage. Regards, Alexander
Old ebuilds dramatically increase the size of the tree. Old ebuilds mean old distfiles stay on mirrors, dramatically increasing the size of the distfiles repository. Production systems should be syncing against local mirrors or using a snapshot if they're not to be updated daily. I am not sure I understand your point about security updates. Were you trying to say that vulnerable versions should stay in Portage?
What I want is just a (maybe second) portage where old ebuilds still could be found. E.g. if a security whole for apache 1.3.6 will be announced in bugtraq, but in the current portage isn't an apache with that version, I think nobody cares and sends out a security-announcement. But what is when 1.3.6 has just been off from portage? Then there are many vunerable system who still using that version. I dont't think attic is a good choice for old or unmaintained ebuilds. Attic is imho a candidate for rm and not as a repository (or history) of old ebuilds.
That sounds more like the GLSA people need to make sure they release GLSAs for application versons that aren't in the current tree.
It's more a call for a second portage where old ebuilds are left so that they won't get lost.
Anyway, this is more an infrastructure issue, not a portage one.
This is a policy and/or process issue to ensure that older ebuilds are maintained for a specified amount of time. Having a set timeframe for keeping ebuilds in the tree will allow users to plan their system upgrades accordingly. It is not reasonable from an infrastructure perspective to expect all ebuilds to be made available indefinitely in portage. This is not something that we can (or should, imo) support. So, to the point of ensuring that users know when ebuilds will be end-of-life'd, I agree and will see if we can get a policy put in place. As for supporting ebuilds indefinitely, that's not something I believe we can support at this time. marking as wontfix.