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.
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
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
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
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.