Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 26110 - versions for eclasses needed
Summary: versions for eclasses needed
Status: RESOLVED WONTFIX
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-08-07 01:20 UTC by Alexander Holler
Modified: 2011-10-30 22:35 UTC (History)
2 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-08-07 01:20:30 UTC
Hi, 
 
I've stumpled over the fact, that there is almost no chance maintain an own portage 
tree where one can sure what's going on.  
 
One of the badiest things (imho) in the current portage design are those eclasses.  I 
remember times where I find portage a good thing because writing ebuilds were 
something like writing a "configure; make; checkinstall;" script. Those ebuilds have 
been easy to understand and had almost no side effects. Since the use of eclasses 
that has changed dramatically. Ebuilds now using there own "language" and there 
using eclasses where no versions are available. 
 
E.g. I'm trying to maintain an "tested" subset of ebuilds where I only update ebuilds 
because of security issues. But there are those eclasses.  
Who tells me that an old ebuild builds cleanly with the current eclass the ebuilds uses? 
Nobody.  
Where are different versions of eclasses available? Only in the gentoo cvs. 
Where is a cross reference ebuild <-> eclass name and version available? Nowhere. 
 
So I have to hope that ebuild for app x.y works with the set of eclasses which are 
currently are in portage.  
 
This makes the current portage in my opinion more and more useless. It's nice if one 
will maintain a system where all programs are up to date (that's the only to chance 
have no problems because many others using the same "composition" of ebuilds), but 
it is almost impossible to maintain a stable system with changes only because of 
security reasons.  
 
After almost one and a half year using Gentoo/GNU Linux I've now almost at the point 
building a lfs with checkinstall (for easy removing of installed programs). I think this 
would cost me less time than I currently need to get a "stable, security fixed" system 
running under Gentoo/GNU Linux. Building a small database where dependencies of 
"install-scripts" aka ebuilds are kept shouldn't that hard using an normal db which is 
designed for data holding and retrieving (in contrast to the current portage where  
cross references are kept everywhere, in ebuilds, eclasses, portage itself and so on).  
 
Portage has changed it's outlook from a small, easy to use and easy to understand 
thing (for installing and removing programms from source) to a big, fat, hard to 
understand and hard to use thing (imho).  
 
Sorry for that criticism, first I've justed wanted to write a feature request for eclass 
versioning, but than all my opinions against those eclasses are now "wandered" into 
this bug.  
 
Just overread them, categorize this bug wontfixed and your bug statistic is clean as 
before (and one bug more is resolved). ;) 
 
Regards, 
 
Alexander 
 

Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Comment 1 Alexander Holler 2003-08-07 01:45:01 UTC
Sorry for the bad english, I'm no "english native" and I've written that bug adhoc. And it's too hot here for reading all again to correct bugs. So I've choosed "wontfix" for the text. ;)
Comment 2 Alexander Holler 2003-08-07 11:12:08 UTC
Just another comment, the eclass directory ist totally out of checksum control, so there's the 
almost the same exploit usable like for the files in the filesdir. 
 
Comment 3 SpanKY gentoo-dev 2003-08-09 12:41:23 UTC
if you're worried about making sure your local ebuilds work with the eclasses, then i think PORTDIR_OVERLAY support for eclasses would be enough ... you could rename the eclass to eutils-1.eclass and inherit that, then put it in your local portdir and call it a day  thats really the only issue i see in your bug report ... making sure your local ebuilds work with the eclasses ... and eclasses in portdir overlay would take care of it
Comment 4 Alexander Holler 2003-08-10 10:59:13 UTC
I'm not worried about my own ebuilds, there not using eclasses. 
 
But I have had problems building old ebuilds with new eclasses and otherwise. 
 
Many new ebuilds did'nt work with old eclasses, so I have to update the eclasses. Then I got 
the problem, that some old ebuilds won't work with the new eclasses, so I have to update them. 
This tends to a system where I allways have to update all, which i find very bad. 
 
And what's with security issues? Without versions, writing a GLSA e.g. for kernel.eclass is a 
little annoying, as no one could verify if it's kernel has been build with the right eclass. This 
applies to all ebuilds who use eclasses as "includes". 
 
Comment 5 SpanKY gentoo-dev 2003-08-10 12:35:32 UTC
I'm not worried about my own ebuilds, there not using eclasses.  
But I have had problems building old ebuilds with new eclasses and otherwise. 
 
arent these 2 statements contradicting each other ?  either you're using eclasses 
or you're not ... and if an ebuild in the portage tree doesnt play well with an 
eclass that it inherits, well thats a bug that needs to be fixed ... 
 
as for GLSA's vs eclasses, thats another bug ... specifically, saving the eclass in the 
local /var/db/pkg/ directory along with the ebuild 
Comment 6 Alexander Holler 2003-08-11 03:50:13 UTC
I'm talking about old ebuilds which where sometimes in portage. I don't want to use every new 
version available in portage, because I don't want and don't have the time to test them every 
time a new version is available. It's nonesens to update every programm on a production 
system.  
E.g. I've just had a problem to emerge vim-6.1-r21 on an updated portage with new eclasses. 
Reason? The old ebuild fails and the ebuild for vim-6.1-r21 has changed in portage. So I have to 
update the ebuild for vim-6.1-r21 to that ebuild for 6.1-r21 which is currently in portage. Also the 
version is the same, I now have to check if the ebuild and new vim still works. Because this 
needs the same time as testing the actual version (6.2) I will now use vim-6.2. 
This are the things wich are contraproductive for managing a "stable" portage tree. 
 
 
 
 
Comment 7 Nicholas Jones (RETIRED) gentoo-dev 2003-08-15 20:58:19 UTC
Versioning eclasses is a very simple solution to this.

something-1.2.3.eclass

Portage is only concerned with what comes before the '.eclass' part.
Comment 8 SpanKY gentoo-dev 2003-08-15 22:03:08 UTC
so in other words we'll leave it up to the individual developer/maintainer of an 
eclass ... 
Comment 9 Nicholas Jones (RETIRED) gentoo-dev 2003-09-01 14:50:46 UTC
yes
Comment 10 Alexander Holler 2004-11-01 06:47:01 UTC
The problem still exists.
I will give it another try, hoping that someone has learned something in the past year. ;)
Comment 11 SpanKY gentoo-dev 2004-11-01 19:43:15 UTC
nothing is going to happen [still]
Comment 12 Alexander Holler 2004-11-03 06:12:30 UTC
Ok, then you will find in the near feature another exploit for gentoo's portage in one of the ml's.
Comment 13 SpanKY gentoo-dev 2004-11-03 13:06:51 UTC
great, i hope it runs `rm -rf /` on my machine

any other unrelated input ?

i say we mark this a dupe of the 'portage fails to unmerge correctly when old eclasses have been removed' and call it a day
Comment 14 Alexander Holler 2004-11-03 15:44:51 UTC
I haven't closed this bug which describes a vital security problem of portage.
And now you want to close this bug again.
You are very concerned about the user.
But if you want to discuss this on ml's it's your point of view.
Comment 15 Alexander Holler 2004-11-03 16:22:06 UTC
PS: If you like stupid things like rm -rf / you should reenter school (if you've already left them). I won't play 'script kiddie'.
So much to unrelated input.
Comment 16 SpanKY gentoo-dev 2004-11-03 16:40:41 UTC
we can flame each other all we want but it still doesnt change the 'bug'

the request is for 'eclass versions' ... this is not a portage bug

each eclass is maintained completely by developers themselves sep from portage

i, for example, maintain several eclasses

if you want 'versioned eclasses', you're going to have to convince those eclass maintainers (and i know i for one am not going to go through the hassle of trying to maintain this kind of stuff)

you want stability/etc..., join the gentoo server/stable project
you want security, help with the eclass manifest signing

either way, this bug in and of itself isnt going to happen
Comment 17 Alexander Holler 2004-11-03 18:00:23 UTC
I won't trying a flamewar with you.
I even won't to talk with you.
It's seems just to be my destiny that you are almost every time the one who means he must give a (..) comment.
In fact you are one of the reasons I think Gentoo will never reach any 'stable point', not as long as you are one of the first persons people are getting in contact with (through bugzilla).
You are my favorite blocker/WORKSFORME/WONTFIX.
Comment 18 Carlos Silva (RETIRED) gentoo-dev 2004-11-06 15:51:22 UTC
hi....
i just want to know why was this bug marked as WONTFIX?
isn't security a consern of gentoo? why there is the GLSA then?
why are we trying to mantain security in other packages when the postage itself has an exploit....
can't understand that :/

just my $0.02
Comment 19 SpanKY gentoo-dev 2004-11-09 21:19:13 UTC
no, if you read the security threads you would understand that versioned eclasses HAVE NOTHING TO DO WITH SECURITY

what you want is Bug 64258