Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 20547 - please leave old ebuilds in portage but mark them with e.g. #x86
Summary: please leave old ebuilds in portage but mark them with e.g. #x86
Status: RESOLVED WONTFIX
Alias: None
Product: Mirrors
Classification: Unclassified
Component: Feature Request (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Mirror Admins
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-05-06 16:40 UTC by Alexander Holler
Modified: 2004-02-18 13:10 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Holler 2003-05-06 16:40:45 UTC
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
Comment 1 Alexander Holler 2003-05-06 18:18:54 UTC
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. 
 
Comment 2 Sven Blumenstein (RETIRED) gentoo-dev 2003-10-28 07:54:23 UTC
Grab them from the Attic if you need them. -> ViewCVS
Comment 3 Alexander Holler 2003-10-29 01:34:47 UTC
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
Comment 4 Jon Portnoy (RETIRED) gentoo-dev 2003-10-29 09:04:03 UTC
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?
Comment 5 Alexander Holler 2003-10-30 09:05:40 UTC
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.
Comment 6 Jon Portnoy (RETIRED) gentoo-dev 2003-10-30 09:18:30 UTC
That sounds more like the GLSA people need to make sure they release GLSAs
for application versons that aren't in the current tree.
Comment 7 Alexander Holler 2003-10-30 09:29:38 UTC
It's more a call for a second portage where old ebuilds are left so that
they won't get lost.
Comment 8 Marius Mauch (RETIRED) gentoo-dev 2004-01-12 04:32:08 UTC
Anyway, this is more an infrastructure issue, not a portage one.
Comment 9 Kurt Lieber (RETIRED) gentoo-dev 2004-01-12 05:03:43 UTC
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.