Installing the sabayon custom /etc stuff in portage profile.

[sprig]

Hi!
My suggestion is simple -

Right now, sabayon installs with very many USE flags, custom masks etc, etc...
Imho, there is some cleaning to do there - for instance ~1.5k packages in the world file, many flags which apply only to one package appearing in make.conf, and packages appearing many times in package.use, etc...

Regardless of that, however, I think it would be beneficial for many users if all these custom settings appeared in a special sabayon portage profile, instead of in the 'live' /etc. some of the benefits: much simpler for users who know what they do to customize various aspects of their system. Much less 'scary looking' config files. Easier to update to newer versions - just have the the profile part of the sabayon overlay - when a user updates the overlay, the default settings get updated (optional of course - can be done via other ways).

Most importantly, it's much more elegant then the current solution

[lxnay]

Mmh... nice idea...
we are also looking for developers and ebuilds maintainers, if you're interested in that

[voxiac]

My impression was that a lot of those entries i /etc/portage/package.* files were added to just make packages to compile...
For instance masking of ktorrent in package.mask comes in mind or compiling some packages with USE="-gtk" to not pull old versions of gtk which ultimately fail to compile.
My method of clean up for the last install was as follows: 'dep -w' + manual clean up of the world file, adjust USE flags, emerge --depclean, remerge some packages I accidentially removed, nuke almost everything in /etc/package.* files since some of the entries were weird in my opinion (later on I discovered of course that some of them were quite sensible).
So my suggestion is to document those tweaks better, like:

Code: Select all

#the following line was added because that package won't compile,
#you can safely remove it when new(stable ?) versions of this package are out

or

Code: Select all

#we compile the following package with USE="-gtk"
#to avoid pulling broken packages (like gtk 1.x)

But regarding your suggestion...
If this stuff is kept in a profile than it has to be maitained very good by the developers (another burden) to ensure no cruft stays in them because those changes would be much harder to track down even for the experienced users. I certainly wouldn't bother checking if those package.* files were changed in the profile and only notice when something goes wrong while emerging. On the other hand if they were to issue a new version of the profile each time a change is made then we'll end up with really many profiles. And even with that it would still be a PITA to upgrade from one profile to the other (e.g. tracking down all the added and removed USE flags and comparing with your make.conf to decide whether you need to explicitely disable one of them or explicitely enable the other).

Regarding that enormous world file...
I'd love to hear some more about why exactly this is so right now. Until now I only heard something about bad dependancy resolution of portage... but can devs elaborate on that please? We may even find an alternative solution by arguing .

[sprig]

lxnay, I'm very flattered for your offer and would love to join the team sometime, but at the moment I'm swamped with work and study and have too little free time to do any serious ebuild maintenance or development....

voxiac - imho the worldfile and the other configs already require some cleanup, and unless it is done, the situation will only get worse... One of the reasons for a profile is so there will be less need for 'cleanliness'... You don't *have* to upgrade your profile, but you might want to if it contains updated masks, AND maybe better default/new useflags, etc... after upgrading a profile all you need to do is emerge -aNDv world and you see all the changed flags that affect you and can easily enable/disable them explicitly.
A profile is not something you frequently update anyway, so even this would not need to be done very often.
Upgrading from 3.3 to 3.4 for instance however, could be as easy as moving from a 3.3 to a 3.4 profile (as is done by gentoo btw).

And you certainly wouldnt want/need to look inside your profile when you update it... the whole point is that you manage your system from your own /etc/portage...

I dont really know, but I suspect that the world file is as large as it is so that updating via emerge -u world work, since when I tried sabayon for the first time, this method was severely broken...

[wolfden]

well with the clean up of loop3 in packages it makes it a lot nicer. 140 some packages removed from world file.

After adjusting configs an emerge -upDN --world was only 508 packages. Instead of 3 days now to recompile the system, it only takes a day. That is a huge improvement. The N flag caused a lot of my packages to be rebuilt, since I changed a lot of USE and CFlags, so an emerge -upD --world would even be lesser.

Messing with config files is great and dandy for the experienced, but the newbs are leaving the config files as is and in turn recompiling more and having more conflicts with installing stuff. Of course this is all learnable if they take the time to learn gentoo.

Wish I knew more to help more with stuff, but I can't program or anything like that. I did make one ebuild with the help of some one once. I guess it's all learnable, but that takes time

[sprig]

wolfden,
I guess it's an improvement, but even with 140 packages removed it is still over 1000 when it could be less then 200... (even that is probably exaggeration).

As for the noobs, they don't have to mess with the files, and having them in a profile will make it harder for them to mess something up by accident. And if someone does need to change a setting, they will probably be much less intimidated at seeing an empty/small file, rather then a file with many lines...

[voxiac]

Wish I knew more to help more with stuff, but I can't program or anything like that. I did make one ebuild with the help of some one once. I guess it's all learnable, but that takes time

I was about to suggest devmanual.gentoo.org but you can't use that one as it's written by evil ciaranm .

2 shwouchk
To put the things straight.

So we have make.conf, package.mask, package.unmask, package.use and package.keywords. What stuff from them exactly do you want to be managed in the profile?
Do you know what is technically possible to put in a profile? (there're some other kind of config files as I see it)
Do you want a profile for every major sabayon release? Or also some minor profile versions in-between?
Will the individual profiles be changed once issued?

[sprig]

You can pretty much put all of it into the profile... so I personally would put all the use flags from make.conf (but not the video cards or input devices or languages, to make them easy to remove), all the custom masks and unmasks and use from /etc/portage, and clean up the world file.

As for the updating, imho a new profile should be issued every release, and not updated once issued, except maybe for bugfixes.

[voxiac]

If all of it is in there... then try to imagine the major headache to undo that stuff...
Consider the following case:
Sabayon devs think they need to mask one of the packages for some reason. I see that that mask is deprecated as packages do in fact emerge and work fine now, so I need to put an entry in my package.unmask : <=category/thatmaskedpackage-version. Notice that I need to keep en eye on version of that package and if I simply add 'category/thatmaskedpackage' I'm already asking for trouble. What if there in fact comes a new version of that package which break everything badly? Which gentoo devs mask but *I* unmask by that entry in my config files. emerge -pvND world won't catch these and I'll notice something only when some reverse dependency of that package won't compile or don't run.
Maybe I'm exaggerating but generally how would we prevent the situations like this from happening:
* They make tweaks
* I make tweaks to their tweaks
* They change something in their tweaks
* My system breaks.

Right now I only see adding global USE flags in the profile as the least potentially harmful option.

P.S. More input is welcome - the more we argue the more we understand potential risks and advantages of this system.

[sprig]

I'm not sure you understand how the profiles system works - you don't 'tweak their tweaks'... You aren't supposed to touch your profile, and it is also not something that changes just every day... you change it when you upgrade to a newer sabayon version - and yes, you CAN sometimes expect to need to fix things when you upgrade. It isn't as if right now you can just emerge -auDvN world even after a clean install, w/o some fixing...

And even so, the profile provides just the basis for your system - it doesn't override stuff youve explicitly put in your configs. you dont need to 'undo' anything... (you might have to do a thing or two when you first change the profile however - but when gentoo 2007.1 or 2008.0 comes, youll also need to do this if youll be using a gentoo profile)

Sabayon devs think they need to mask one of the packages for some reason. I see that that mask is deprecated as packages do in fact emerge and work fine now, so I need to put an entry in my package.unmask : <=category/thatmaskedpackage-version. Notice that I need to keep en eye on version of that package and if I simply add 'category/thatmaskedpackage' I'm already asking for trouble.

How is this different from what goes on today? you are (probably) on the ~x86 tree anyway which means that keyworded packages are emerged by default.. and as for masked packages, youre right about asking for trouble - and you probably also don't want to .unmask all future versions anyway, so what's your point?

What if there in fact comes a new version of that package which break everything badly? Which gentoo devs mask but *I* unmask by that entry in my config files. emerge -pvND world won't catch these and I'll notice something only when some reverse dependency of that package won't compile or don't run.

If *you* unmask something, it is your responsibility to see that it doesn't break your system - again, how is this different from today's situation?[/quote]