What needs to be improved in Gentoo?

[Cinquero]

...

I think that all of your requests are already fulfilled. The samba problem can be solved by extending the ebuild. The branches actually already exist in a flexible form through the arch keywords (although there could be some systematic improvements be done yet).

A rant on portage/profiles/package.mask:

Why do we need to mask packages like porthole-0.5.0*? That package is not critical for the base system. Please refrain from cluttering package.mask with such entries.

[steveL]

I think that all of your requests are already fulfilled.

Er.. are they? /All/ of them?

One thing I'd like to see is per-package overrides/ appends on stuff like CFLAGS (eg if I want to debug a package, I'd set an override to take away -fomit-frame-pointer and add -g) and LDFLAGS (eg add Wl,z,now for QA notices such as xorg is `setXid, dyn linked, and using lazy bindings').

How do I do this then?

A bigger change would be the one to have an unstable (current testing), testing and stable set. It seems from what others have said that testing can be too bleeding edge and stable can significantly lag behind upstream.

This certainly hasn't been addressed. (It's not my idea, it just makes sense.)

[contentious]I'd also like to see packages like samba with the option of only compiling the client, in line with the philosophy of only having what you need. I understand this can be done by unpack and configuring, I'd just like it automated.

The samba problem can be solved by extending the ebuild. The branches actually already exist in a flexible form through the arch keywords (although there could be some systematic improvements be done yet).

That's kinda what I said, although I didn't mention extending the ebuild as such. I agree it could be done better.

Further, I don't think it helps us when a standard upgrade breaks a system.[/contentious]

This certainly hasn't been sorted out, as the number of people whose system has b0rked shows. (Indeed one veteran put it as gentoo is not appropriate for you if you mind a system update breaking your (graphical) login. And from what I've read it could be your CL login, although I have doubts on that.)

A rant on portage/profiles/package.mask:

Why do we need to mask packages like porthole-0.5.0*? That package is not critical for the base system. Please refrain from cluttering package.mask with such entries.

From my understanding, it's not a question of whether it's critical for the base system, but whether it should be hardmasked or not, irrespective of what it's for. Or am I missing something? (Wouldn't be the first time )

[Cinquero]

One thing I'd like to see is per-package overrides/ appends on stuff like CFLAGS (eg if I want to debug a package, I'd set an override to take away -fomit-frame-pointer and add -g) and LDFLAGS (eg add Wl,z,now for QA notices such as xorg is `setXid, dyn linked, and using lazy bindings').

How do I do this then?

Where do per-package overrides of that sort make sense? Many ebuilds make sure that compiler optimizations are kept at a sane level. There are also the mmx, 3dnow, sse use flags. Additionally, you can modify the build process via the FEATURES variable: look at "debug" and "nostrip" keywords. If you need to debug a package, do a 'FEATURES="debug nostrip" emerge pkg' or 'CFLAGS=-g LDFLAGS=... emerge pkg' or so.

A bigger change would be the one to have an unstable (current testing), testing and stable set. It seems from what others have said that testing can be too bleeding edge and stable can significantly lag behind upstream.

This certainly hasn't been addressed. (It's not my idea, it just makes sense.)

You have that through the arch keywords. If "stable" lags behind, what would a "stable set" change if it is just another way to organize things? You need developer power to fix that, not another structure. Tell me if I'm wrong at that.

Further, I don't think it helps us when a standard upgrade breaks a system.
This certainly hasn't been sorted out, as the number of people whose system has b0rked shows. (Indeed one veteran put it as gentoo is not appropriate for you if you mind a system update breaking your (graphical) login. And from what I've read it could be your CL login, although I have doubts on that.)

I have had such incidents (even on the console) but all were related to a bad configuration setup. Gentoo does not provide an automatic configuration mechanism, so you can easily break such things if you don't know what you are doing. If, for example, some pam module gets removed/renamed/moved or pam submodules get refactored, it is very likely that your pam setup won't allow you to login any more if you did not adjust the config files correctly. For example, when switching between SELinux and non-SELinux profiles, one may also choose to remove the SELinux libs -- which can be fatal since the pam SELinux module is not configured as "optional" by default.

A rant on portage/profiles/package.mask:

Why do we need to mask packages like porthole-0.5.0*? That package is not critical for the base system. Please refrain from cluttering package.mask with such entries.

From my understanding, it's not a question of whether it's critical for the base system, but whether it should be hardmasked or not, irrespective of what it's for. Or am I missing something? (Wouldn't be the first time )

Probably. Don' think that is a good solution. I'd rather have "~~arch" keywords for that purpose (=unstable/not working). Coming back to the porthole masking issue: the comment just says that it is there for testing. It always worked for me quite fine, so there is absolutely no reason why to mask it -- at least not one I am able to identify. I even wonder why it is considered as unstable.

What definitely needs to be improved, is the way one edits forum posts. This is a lot more complicated than using email (regarding quotes). PLEASE fix that. Why can't we just use quoting like in eMails? Or give the user the choice to do so? Maybe by introducing a special content format that triggers a colorized display of quotes?

[Dralnu]

Where do per-package overrides of that sort make sense? Many ebuilds make sure that compiler optimizations are kept at a sane level. There are also the mmx, 3dnow, sse use flags. Additionally, you can modify the build process via the FEATURES variable: look at "debug" and "nostrip" keywords. If you need to debug a package, do a 'FEATURES="debug nostrip" emerge pkg' or 'CFLAGS=-g LDFLAGS=... emerge pkg' or so.

This is annoying to do, and when you have to update, it adds quite a bit of time to the update proccess since yo have to emerge everything BY HAND and then remember what you had set a set of features to, CFLAGS, ect. It isn't a viable solution.

From my understanding, it's not a question of whether it's critical for the base system, but whether it should be hardmasked or not, irrespective of what it's for. Or am I missing something? (Wouldn't be the first time )

Probably. Don' think that is a good solution. I'd rather have "~~arch" keywords for that purpose (=unstable/not working). Coming back to the porthole masking issue: the comment just says that it is there for testing. It always worked for me quite fine, so there is absolutely no reason why to mask it -- at least not one I am able to identify. I even wonder why it is considered as unstable.[/quote]

Some packages are masked because there is no maintainer for it. I don't know the particular reason to hardmask porthole since I don't use it, but that is a problem. Another example is IceWM and Openbox. What is keyworded there works fine. Sometimes things are slow, or they just aren't maintained. If you feel it should be marked stable, see about supplying a bug report for it to be marked as such. If it gets through, good. If not, oh well.

[steveL]

Where do per-package overrides of that sort make sense? Many ebuilds make sure that compiler optimizations are kept at a sane level. There are also the mmx, 3dnow, sse use flags. Additionally, you can modify the build process via the FEATURES variable: look at "debug" and "nostrip" keywords. If you need to debug a package, do a 'FEATURES="debug nostrip" emerge pkg' or 'CFLAGS=-g LDFLAGS=... emerge pkg' or so.

As I said, where I want to work on (ie debug) a package; as Dralnu said this isn't a viable solution. (But thanks for pointing out the `nostrip' feature.)

A bigger change would be the one to have an unstable (current testing), testing and stable set. It seems from what others have said that testing can be too bleeding edge and stable can significantly lag behind upstream.

You have that through the arch keywords. If "stable" lags behind, what would a "stable set" change if it is just another way to organize things? You need developer power to fix that, not another structure. Tell me if I'm wrong at that.

Well, I guess what I mean is that packages which are known to compile on say the package maintainers system (and hopefully one or two more) would be unstable (same as current.) Then when there's been x (eg 50) positive reports they could go in testing. Stable would be for stuff that is guaranteed to compile and work (like Debian stable) and would imply production-ready status.

I guess it could be argued that hardmasking is used to bring in packages like that, but I don't think so- hardmasking implies there's something broken.

The point is there's large middle ground between unstable/bleeding-edge packages and production-ready stuff (which gentoo is effectively putting its rep on the line about) and it makes it awkward for the user. (adding to keywords, being careful about future updates which may well be broken etc.)

While this would indeed need devs to help out (what wouldn't!), I think a distinction needs to be made between ebuild devs (ie QA and maintenance) and actual coders (eg portage devs.) In that sense, having a testing middle ground could take pressure off the maintainers, as we could simply have a user vote (or pref an automated system based on feedback) on whether to move a package from unstable to testing. And this wouldn't compromise production systems (or gentoo's rep) while allowing ebuild devs to concentrate on maintaining ebuilds, and QA to mark as stable.

I have had such incidents (even on the console) but all were related to a bad configuration setup. Gentoo does not provide an automatic configuration mechanism, so you can easily break such things if you don't know what you are doing. If, for example, some pam module gets removed/renamed/moved or pam submodules get refactored, it is very likely that your pam setup won't allow you to login any more if you did not adjust the config files correctly. For example, when switching between SELinux and non-SELinux profiles, one may also choose to remove the SELinux libs -- which can be fatal since the pam SELinux module is not configured as "optional" by default.

Yeah, I've heard about that somewhere, and frankly it seems shocking that it hasn't simply been changed- one config file change! OK, it may not technically be a bug, but it breaks the system. A user isn't going to care why.

A rant on portage/profiles/package.mask:
Why do we need to mask packages like porthole-0.5.0*? That package is not critical for the base system. Please refrain from cluttering package.mask with such entries.

From my understanding, it's not a question of whether it's critical for the base system, but whether it should be hardmasked or not, irrespective of what it's for. Or am I missing something? (Wouldn't be the first time )

Probably. Don' think that is a good solution. I'd rather have "~~arch" keywords for that purpose (=unstable/not working). Coming back to the porthole masking issue: the comment just says that it is there for testing. It always worked for me quite fine, so there is absolutely no reason why to mask it -- at least not one I am able to identify. I even wonder why it is considered as unstable.

What does that have to do with it being `critical for the base system' (your original rant)?
The example you're giving kinda highlights the need for a `testing' as opposed to `unstable' keyword. A package like that shouldn't be hardmasked, it should be unstable as it compiles and runs.

If there's no maintainer, it's hard to see how it could ever go into stable.

What definitely needs to be improved, is the way one edits forum posts. This is a lot more complicated than using email (regarding quotes). PLEASE fix that. Why can't we just use quoting like in eMails? Or give the user the choice to do so? Maybe by introducing a special content format that triggers a colorized display of quotes?

Yeah, these last coupla posts were a nightmare!

[Cinquero]

Yeah, these last coupla posts were a nightmare!

Need to stop that now .

But I agree on the stability issues. One could probably create a modified really-stable portage tree by deploying a package usage statistics/error reports/build logs collector and using the results to (largely automatically) adjust the arch keywords... no need to wait for the Gentoo devs to consider that a viable thing to do.

[steveL]

Yeah, no more nesting!

But I agree on the stability issues. One could probably create a modified really-stable portage tree by deploying a package usage statistics/error reports/build logs collector and using the results to (largely automatically) adjust the arch keywords... no need to wait for the Gentoo devs to consider that a viable thing to do.

From what I can tell, the current stable tree /is/ really stable. At least a common complaint is that it lags significantly behind upstream development, and that's understandable given that gentoo is going for a `corporate-ready' distro as one of its goals.

Tho how on earth they reconcile that with cock-ups along the lines of the selinux stuff I have no idea.

IMO the structure needs changing- it would make it easier for users and devs, as outlined above. And those kinda messups wouldn't ever get to stable, which can only enhance gentoo.

[Cinquero]

Yeah, no more nesting!

But I agree on the stability issues. One could probably create a modified really-stable portage tree by deploying a package usage statistics/error reports/build logs collector and using the results to (largely automatically) adjust the arch keywords... no need to wait for the Gentoo devs to consider that a viable thing to do.

From what I can tell, the current stable tree /is/ really stable. At least a common complaint is that it lags significantly behind upstream development, and that's understandable given that gentoo is going for a `corporate-ready' distro as one of its goals.

app-editors/nvu does not even compile on x86 although it is declared as stable since ages.

And that is only one example. If you only compile system packages plus the usual mainstream stuff, it is pretty clear why you consider the stable branch as "really stable"...

BTW: I have got the impression that ccache is by far not optimal when handling source files for which the preprocessor consumes a large amount of CPU time. Is it correct that ccache does not cache preprocessing output? The same seems to apply to distcc (where it is necessary to avoid the requirement that the complete system is identical). And I guess that there are reasons for ccache in not doing so... like complications due to arch-specific MACRO defs etc.?

Update:

To make portage more consistent, the use of methods (in ebuild files) that circumvent the sandbox (methods that install/alter files not recorded in the CONTENTS file) should be strongly discouraged (maybe by adding ebuild QA checks). If you want to have a list of all files not contained in the CONTENTS files, use my script "mscript-tools FindStaleFiles /usr". .pyo and .pyc files could be generated during package compilation inside the sandbox, for example. It would nonetheless be better to use some package rebuild trigger mechanism instead of a manual python-updater script. In the end, that would allow for a fully transactional portage operation.

Update 2:

add a "delayable" flag to init scripts which are not critical for a fast start-up (cups, ntpd, sshd etc.). Start them after the non-delayable services have been started, maybe after an additional waiting time of 10 seconds or so.

Update 3:

(KDE) desktop startup cache. Fedora pre-caches system filess accessed during startup to make startup faster. That is somewhat complicated because it needs to be done using two separate computers. However, pre-caching the KDE startup would be much easier because the system is already up and running. (of course, using a self-optimizing block device driver/handler (doing block re-sequencing and duplication to let most frequent read sequences result in burst transfers without head seeks) would be more generic and therefore probably much more useful)

Update 4:

revdep-rebuild should also check whether libraries and programs are older than the libs against which they are linked.

[steveL]

app-editors/nvu does not even compile on x86 although it is declared as stable since ages.

And that is only one example. If you only compile system packages plus the usual mainstream stuff, it is pretty clear why you consider the stable branch as "really stable"...

OK, you know better than I on this; so there is scope to establish a `really stable' tree.

BTW: I have got the impression that ccache is by far not optimal when handling source files for which the preprocessor consumes a large amount of CPU time. Is it correct that ccache does not cache preprocessing output? The same seems to apply to distcc (where it is necessary to avoid the requirement that the complete system is identical). And I guess that there are reasons for ccache in not doing so... like complications due to arch-specific MACRO defs etc.?

Dunno; I stopped using gentoo a couple of years ago (around the time of 1.4) when some changes meant I couldn't update the development server I was trying to present to my work as a prototype for a new system. Much embarrassment (especially as I was evangelising for Linux v Windows) and so I never got into distcc and ccache.
I've only rejoined in the last month (had problems with some of the earlier install disks, so carried on using Mandrake) and now only use it on my workstation.

It didn't sound right to me, so I looked up the proj homepage:

CCACHE_CPP2
If you set the environment variable CCACHE_CPP2 then ccache will not use the optimisation of avoiding the 2nd call to the pre-processor by compiling the pre-processed output that was used for finding the hash in the case of a cache miss. This is primarily a debugging option, although it is possible that some unusual compilers will have problems with the intermediate filename extensions used in this optimisation, in which case this option could allow ccache to be used.

This implies that there is /some/ optimisation but perhaps not what you'd hope for, prob'y for the reasons you gave.
HTH.

[tylerwylie]

Gentoo is near-perfect for me. Things I would change:
Logo
I don't hate the cow
but I don't like cows.

[emerge_myself]

I haven't read through all the messages in this topic, so I might be repeating what someone has already suggested in the past. But here it goes anyway

One thing that could be done is to use svn/cvs to host the portage tree. That way we automatically get branches. This way the head branch would be equivalent to having all packages unmasked. The testing branch would be equivalent of ACCEPT_KEYWORDS=~arch and then there would be release specific branches like 2006.1,2006.0 etc. This way the need for a stable branch is fulfilled. Of course the downside is that someone would have to submit security/bug fixes to the older branches, which goes againts gentoo's "Upgrade to latest for fixes" philosophy. But it is a minor detail which can be resolved.
In any case the current profile will specify what branch to check the portage tree out off. In this case the package.keywords will specify what branch to check that particular package out off. This way if someone is using 2006.0 branch then he/she will not get a package from a newer branch till he/she decides to upgrade to a branch.

Once again if this has been discussed in the past my apologies for bringing it up once more. Cheers

[steveL]

I like that idea; it would make it easier to maintain a release as well (eg if you didn't want to bump to gcc4 for another couple of months.)

You'd need some sort of script/s to automate the multi-revision tho.

[tuxicated]

The thing that bothers me most about GENTOO is this:

There is no way you can do an unattended "emerge world" without risk of breaking a system

There is too much 'babysitting' involved in updating a system. It would be great if you could emerge only those updates that are safe and don't require your attention.

For example, I would like to login on a remote GENTOO system, do:

Code: Select all

nohup emerge world --only-trivial-packages &

and logout without worrying about people calling me about why I broke their systems again. Also, I would like to be able to exclude updates that require system services (apache, squid, sshd, ...) to be restarted:

Code: Select all

nohup emerge world --only-trivial-packages --no-services &

This would make remote system administration a lot less frustrating.

[dol-sen]

Sorry I didn't catch this earlier.

dranlu wrote:

Code: Select all

I don't know the particular reason to hardmask porthole since I don't use it, but that is a problem. 

Porthole-0.5.0 got hardmasked due to a singlr gtk bug that caused a segfault if the conditions were right. That bug was found by the dev that was reviewing my ebuild & release for inclusion in the tree. So he hard masked it. There is a workaround to prevent the segfault by forcing a refresh or column sort before switching back to any of the other views from the upgrades view (if you expanded the "Dependencies").

The irony of it is that porthole-0.4.x has (still) several causes of segfaults (unpredictable ones) that have all been fixed in -0.5.0 along with many other improvements. But they have never been hardmasked.

I have changed the interface again to avoid that gtk bug and also improve portholes interface some more, but I have been far too busy this year to finish things and make a release. I have had a chance to work on it again lately. I will announce when it is ready for testing in the Unsupported Software forums.

[Corona688]

What I would like is the ability to emerge --sync without it removing ebuilds for packages I have installed. If it's going to gnaw off my leg like that, it should at least give me a suture kit by doing a --buildpkg on the things in question before it removes my ability to build that package version ever again.

I mean, the portage tree is in CVS, right? Why can't I roll back my portage tree?

[tuxicated]

before it removes my ability to build that package version ever again.

Well, when packages disappear from the tree, they also disappear from the download mirrors. You need to keep your own copy of the source tarball as well...

[Roman_Gruber]

I would like to have in the bash shell only displayed once a command if i press up.

Now if you press up, i get several times the same command, before i get another command, because i have entered before several times the same command. So i have to hit the up arrow to many times. This should be improved.

Its something about the history funcition in the bash shell.

With history -c everything is cleared.

Also if i update my system, it alos breaks my system reguarly. Thats really worse, else i like gentoo, also the logo.

[Corona688]

before it removes my ability to build that package version ever again.

Well, when packages disappear from the tree, they also disappear from the download mirrors. You need to keep your own copy of the source tarball as well...

OK. Add that too.

The whole thing could be handled in something close to a portage overlay, I suppose.

[Corona688]

I would like to have in the bash shell only displayed once a command if i press up.

Now if you press up, i get several times the same command, before i get another command, because i have entered before several times the same command. So i have to hit the up arrow to many times. This should be improved.

Try pgup. Only works with a partial command though.

[dyeu]

I would like to have in the bash shell only displayed once a command if i press up.

Now if you press up, i get several times the same command, before i get another command, because i have entered before several times the same command. So i have to hit the up arrow to many times. This should be improved.

Try pgup. Only works with a partial command though.

Append "&" to HISTIGNORE in your ~/.bashrc, as in:

Code: Select all

export HISTIGNORE="&:l:ll:ls:pwd:[bf]g:exit:clear"

[Drysh]

First of all, I would like to say that I love Gentoo. This is the best (meta)distro because it combines flexibility with easyness. Cheers to all developers. That said, I would like to express some points where I think Gentoo should improve. Most of them are because Gentoo is so big now that some solutions that worked in the past need to be re-thinked.

1. USE flags
1.a. Name conventions
Today there are so many use flags that is very difficult to remember each one. Like many huge projects did with variables, we need to change from the short naming style to long descritive names. As an example, to set apache support, we have 3 flags: apache, apache1 and apache 2. (Oops.. When looking for the descriptions I couldn't find apache1 flag. But I'm sure I saw it somewhere. That's what I mean with "hard to remember".) How about something like:

net.www.apache = set support for apache (for the version avaliable in the stable tree)
net.www.apache.version_1 = set support for apache forcing version 1
net.www.apache.version_2 = set support for apache forcing version 2

This may be longer, but it will actualy save us time because it will be much easier to know what a flag does.

1.b. Other flags
There are video, input_device, linguas, etc... How about unifying them all?

2. The tree
2.a. Consistency
We need some rules to consistently locate thing on the tree. There is net-www/apache and www-apache... Why isn't apache in www-apache? What does www-* mean and how is it different from net-www? What should go in one or the other?

There are some ebuids that aren't used to install packages, but actualy to set configurations and extras. I'm talking about things like [[the one that is used to make win-codecs work]] and [[firefox flash plug-in]]. There are two problems here:

2.b. A single way to set things.
Having different ways to set similar things is confusing. There are things set using use flags, some need an extra emerge, and some may even be instaled using the application internal installer. It's great to have options, but not when this options make it difficult to understand how someone set something. If we can install firefox plug-ins using emerge, we should de-activate the internal installation function and give a message like "To install plug-ins use emerge mozilla-plugin-plugin_name". It would be ideal if we could set everything using flags, and extra ebuilds should be emerged automaticaly.

2.c The un-emergeable ebuilds
Those ebuilds that aren't suposed to be emerged should be moved to a different location to prevent confusion and clean the tree. I mean the ebuilds that are automaticaly installed when you set a flag. How about an "aux" directory in the tree, copying ll the tree hierarchy there, and moving these ebuilds there? That way, when someone browse the tree, it would be easier to find relevant ebuilds. (Those thousands of modular xorg e-builds should go there.)

3. Directories and locations
3.a Why is the tree and distfiles in /usr? Why is "world" in /var? Word only changes when you install something in your system, so it should be in /etc. The tree and distfiles change a lot (every emerge --sync). How about putting the tree in /var/gentoo/tree and the distfiles in /var/gentoo/distfiles ??? It's just a matter of changing the default. I already do this and I have to tell you: things run better this way. The /var directory is optimized for heavy use, while hte /usr directory is optimized to be solid (well, I optimize them this way because services need /var to be fast and the system needs /usr to be avaliable after a failure (if you hope to fix things)).

3.b We should move some configurations from make.conf. Use flags aren't make configurations. They are gentoo configurations. How about creating /etc/gentoo and putting these configurations there? I think the world file should also be placed there. That way, make.conf should only be changed when you are changing how you want "make" to behave. Use flags change far more often than the rest of make.conf.

3.c This isn't a critical suggestion at all, but I think it's a good idea. We have this .keep files that are used to say that a directory shouldn't be removed. How about putting something in this files: a description of the directory, what should be in it, and why it shouldn't be removed. Well, when you see a .keep file and want to know why it is there, you will only have to open that file and read. Genial, right?

Well... There are some other suggestions, but I'm without time now. I'll continue this latter. BTW, I`m willing to help implementing these if you like them. I'm not able to do everything by my self, but with some help, I'm sure it's possible to do this. Comments are (very) welcome.

[Corona688]

First of all, I would like to say that I love Gentoo. This is the best (meta)distro because it combines flexibility with easyness. Cheers to all developers. That said, I would like to express some points where I think Gentoo should improve. Most of them are because Gentoo is so big now that some solutions that worked in the past need to be re-thinked.

1. USE flags
1.a. Name conventions
Today there are so many use flags that is very difficult to remember each one. Like many huge projects did with variables, we need to change from the short naming style to long descritive names. As an example, to set apache support, we have 3 flags: apache, apache1 and apache 2. (Oops.. When looking for the descriptions I couldn't find apache1 flag. But I'm sure I saw it somewhere. That's what I mean with "hard to remember".) How about something like:

net.www.apache = set support for apache (for the version avaliable in the stable tree)
net.www.apache.version_1 = set support for apache forcing version 1
net.www.apache.version_2 = set support for apache forcing version 2

This may be longer, but it will actualy save us time because it will be much easier to know what a flag does.

If we have to use use flags like that, we'll soon be pushing the boundaries of what'll fit on the screen at one time, not to mention a commandline.

This has been partially dealt with via /usr/portage/profiles/use.desc. But it needs to be seriously mantained, not this "optional" thing they've got going right now.

1.b. Other flags
There are video, input_device, linguas, etc... How about unifying them all?

Bad idea. See objections to 1a.

2. The tree
2.a. Consistency
We need some rules to consistently locate thing on the tree. There is net-www/apache and www-apache... Why isn't apache in www-apache? What does www-* mean and how is it different from net-www? What should go in one or the other?

There are some ebuids that aren't used to install packages, but actualy to set configurations and extras. I'm talking about things like [[the one that is used to make win-codecs work]] and [[firefox flash plug-in]]. There are two problems here:

2.b. A single way to set things.
Having different ways to set similar things is confusing. There are things set using use flags, some need an extra emerge, and some may even be instaled using the application internal installer. It's great to have options, but not when this options make it difficult to understand how someone set something. If we can install firefox plug-ins using emerge, we should de-activate the internal installation function and give a message like "To install plug-ins use emerge mozilla-plugin-plugin_name". It would be ideal if we could set everything using flags, and extra ebuilds should be emerged automaticaly.

You know, this sounds reasonable except for two things.

1) Moving things around in the tree is a bad idea unless absolutely necessary. Because of the way the tree is completely replaced every sync, this causes weird inconsistencies.

2) If they made flash an optional dependency right now, they'd probably default it to something GPL yet broken like gnash

3. Directories and locations
3.a Why is the tree and distfiles in /usr? Why is "world" in /var? Word only changes when you install something in your system, so it should be in /etc. The tree and distfiles change a lot (every emerge --sync). How about putting the tree in /var/gentoo/tree and the distfiles in /var/gentoo/distfiles ??? It's just a matter of changing the default. I already do this and I have to tell you: things run better this way. The /var directory is optimized for heavy use, while hte /usr directory is optimized to be solid (well, I optimize them this way because services need /var to be fast and the system needs /usr to be avaliable after a failure (if you hope to fix things)).

Tradition. It'd be difficult to change things now... Imagine being told that, for the 2007.1 profile, you'd have to move all sorts of crap around?

3.b We should move some configurations from make.conf. Use flags aren't make configurations. They are gentoo configurations. How about creating /etc/gentoo and putting these configurations there? I think the world file should also be placed there. That way, make.conf should only be changed when you are changing how you want "make" to behave. Use flags change far more often than the rest of make.conf.

Well, make configuration is also gentoo configuration since you won't find a make.conf on, say, fedora. And it definitely doesn't control how the application named 'make' works, except indirectly, and then only inside portage.

I think they designed portage to be sort of "on top" of the system rather than inside it, hence it's position inside /usr instead of /etc.

Also, /etc is one of the protected directories. Wouldn't you hate having to do that ._configfile_0001 dance every time you changed your world file? Best to have it outside rather than complicating the code with all the landmines a special case for a special case means.

3.c This isn't a critical suggestion at all, but I think it's a good idea. We have this .keep files that are used to say that a directory shouldn't be removed. How about putting something in this files: a description of the directory, what should be in it, and why it shouldn't be removed. Well, when you see a .keep file and want to know why it is there, you will only have to open that file and read. Genial, right?

Pretty easy to do if you're willing.

[A.M.F]

thanks a lot, very usefull tips.

[Drysh]

Please, more comments! I also added a pool for some feed-back.

@developers: Am I insane proposing these? Are they difficult to implement?
@users: Would these help you? What else would you suggest to organize things?
@system-admins: Would these help you use gentoo in a corporate environment?

Note that all these suggestions are about organization of gentoo, I'm not talking about new features or something alike. The idea is to organize what we already have.

[lxnay]

Erase GLI and use Anaconda :p
And maybe adding reverse deps management to Portage.