Bugzilla Bug 26110

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.

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

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. 

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

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

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 

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. 

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.

so in other words we'll leave it up to the individual developer/maintainer of
an 
eclass ... 

yes

The problem still exists.
I will give it another try, hoping that someone has learned something in the past year. ;)

nothing is going to happen [still]

Ok, then you will find in the near feature another exploit for gentoo's portage
in one of the ml's.

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

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.

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.

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

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.

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

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