Gentoo Forums

Rad wrote:

c0d3g33k wrote:Good points, though perhaps missing mine, which was about whether users are capable of deciding if Gentoo needs to be careful or take bigger risks. The point being that the time for taking big risks has passed for various reasons and folks wanting radical and risky changes might better seek them elsewhere.

But what is a "big risk" here? Are you saying developers willfully allow broken packages into Gentoo stable and hoping that users don't complain? Or was it something else?

Something else. All your points are good and I don't disagree, but my mind was working at a higher level of abstraction. (Actually several simultaneously, which doesn't help clarity when trying to be succinct at the same time, particularly with all that's going on in a topic like this). What's fascinating me about this whole business are the organizational and social aspects not the technical ones. The types of risk I'm considering but not elaborating on include social, cultural and organizational ones, not just technical. The original trigger for thinking about this was the discussion of the alternate package managers and reverse deps. If it's just about technical risk, the technically superior solution that addresses the "hard targets" and doesn't break anything much would be adopted and that would be that. But there's some social risk involved which is potentially disruptive, so that holds things back too. Lump all that together with considering the cost of change over the lifetime of projects, the relative maturity of Gentoo, the clear need for stability on the part of the community plus personal experience with organizational cultures and out pops the conclusion I drew.

cyrius wrote:Can we select a limit date to sync with the attic ?
I mean if i want to have all ebuilds valid before 06/06/2007, there is a way ?Use of subversion ?

Didn't drobbins try that already? Oh. Wait. Sorry. You meant the version control system.

c0d3g33k wrote:What's fascinating me about this whole business are the organizational and social aspects not the technical ones. The types of risk I'm considering but not elaborating on include social, cultural and organizational ones, not just technical. The original trigger for thinking about this was the discussion of the alternate package managers and reverse deps. If it's just about technical risk, the technically superior solution that addresses the "hard targets" and doesn't break anything much would be adopted and that would be that.

Yes, but neither of the alternative package managers does that yet. So neither is a serious candidate for adoption yet, since both have reported bugs which stop them building the whole tree. (Just ask Patrick/bonsaikitten: he routinely builds the whole tree for his tinderbox.) It'd be simple to prove that a PM is good enough for consideration imo: can you build a stage3 using catalyst with it?

But there's some social risk involved which is potentially disruptive, so that holds things back too. Lump all that together with considering the cost of change over the lifetime of projects, the relative maturity of Gentoo, the clear need for stability on the part of the community plus personal experience with organizational cultures and out pops the conclusion I drew.

There are social issues I agree. Part of the problem imo has been the dev unwillingness to discuss any such matters when users bring them up. It's fine for devs to discuss non-technical matters on the dev m-l, but not users. The project mailing list is an attempt to change that by providing a space where non-technical aspects of development, which are critical afaic, can be discussed. I'd recommend any user who's interested to join that list. Reading over nntp is fine, it's an open list like dev, so you can post via your newsreader. Just remember that every post is an email in the inbox of every person who reads it via email (which most devs do, afaict.) Not every dev reads it, ofc, just like many stopped reading the dev m-l as they got fed up of flames which had nothing to do with the technical side of things.

Personally I think it's fine for a dev to be interested in only the technical stuff (I'd be worried if that wasn't their main concern.) That doesn't stop the other things being important, nor does it mean they won't affect him/her. On that side, devs who are not ebuild devs (like forum mods for example) have a lot more relevant experience, and should be given greater weight. I don't know how that would work, only that if we are talking about the social and political aspects, ebuild maintainership is no indication of relevant experience. If anything, most technical people are less capable of dealing with social issues.

I wonder what on Earth happened to the DRobbins offer..

As for Gentoo, I'm on my lookout for another source-based or source-enabled distro, one that doesn't produce horrific breakage every 3 months. I had a working install bail out from under me a month ago. I see there have been some discussion as to whether the devs should be concerned with stability or with being up-to-date. It's a shame really to say that they are failing at both at the same time.

And while I see that there is a shortage of devs - no surprise really, with all the trolling going on -, at least some of the issues could be solved by prioritization of problems. The main shortcoming of gentoo lies in the ebuild format and portage. With a new repo format - not silly PR activities, like implementing a new signing system and removing per-package Manifests, but REAL redesign from bottom up - we could even be going somewhere. We could have true multilib, for example. No more need for revdep-rebuild, and most of all no more need for emerge -e world, which is the screaming symptom of a fundamentally broken package management system.
Of course ebuilds could be kept as a legacy format. First only the core packages would need to be migrated, with the enermous userland left in the old repo, and gradually migrating those too.

Speaking of package managers, I find the suppression of Paludis quite comical - it's obviously a personal issue, and personal issues dictating technical conduct is another good reason for getting off the Gentoo bandwagon for good. While Paludis doesn't solve all the former problems in itself, it opened lots of pathways that could have lead out of the Gentoo tarpit.
Devs like to comment on it not building all ebuilds. (Makes me think of the Browser Wars of 2000 - of course it was all Netscape's fault, not that of the pages with shitty markup.) Maybe it doesn't. Mostly it's only the test phase that fails because of the sandbox. I wonder if portage runs the test phase by default... If I'm not mistaken, it doesn't.
Anyway, Paludis has a way of referencing repositories (and thus masking or unmasking a package by repository), supports several package formats, and handles dependencies correctly. And it builds 49 out of 50 packages correctly. Fixing the few problematic ebuilds would pose no real problem, considering that we do have occasional ebuild breakage in the tree under portage too.
Sure, it's not the holy grail. It would be a step in the right direction. But sure, it's much more fun poking paludis devs and users around, and defending portage in screaming fits of rage than getting down to work on the ruddy thing.

And no, removing per-package Manifests is not a step. It's PR. Sand to throw in the eyes of users. "Steps" would have something to do with dependency tracking, the basic underlying logic of package management and such. Heck, even the concept of USE flags would welcome a redesign. They're getting too numerous to handle.
Also did anyone notice that ebuilds have no clean way of declaring "drop-in replacement"? Sure, we have virtual, which is cumbersome and misses the whole point. Say, I have a drop-in replacement for a library not in virtual, like, for example aalib. I can do one of two things: create an ebuild for it under a fake name of aalib and a fake version number something like 9999.1 so it would install and take its rightful place in the deptree, or I can take every single ebuild depending on aalib, and migrate them to depend on virtual/aa, create virtual/aa, modify the aalib ebuild and then I can insert my drop-in replacement. Sounds like a Monty Python sketch, but it's the Gentoo truth.

Also, there is some default behavior that would need a different view at things. Take unicode for example. It's 2008, and Gentoo still doesn't ship with unicode (widechar support) as a default. No, the "unicode" flag doesn't do it. All binary distros come with unicode, but to get unicode REALLY working in Gentoo, one needs to hack away at the ncurses ebuild, cut half of it out, and write some patch code himself. And ncurses is ACTIVELY DEVELOPED, with a really fat ebuild full of ifs and cases. All boiling down to no unicode in two-thirds of ncurses apps. (I guess the English-speaking devs living happily with the ASCII charset don't even notice the problem.) Redhat ships midnight commander with a unicode patch. Gentoo doesn't.

All in all, returning to the first statement... Instead of overall stability or up-to date functionality, gentoo seems to revolve around making sure things will go smoothly in certain improbable and never before encountered scenarios, while leaving screaming breakages wide open that people come across and live with day to day and complain about. Putting Paludis off for not compiling 1 out of 100 ebuilds is just a perfect example of this mentality, and it leads right down into the tarpit.

Anyone know of a good source-enabled distro, possibly with corporate backing?

Simius wrote:I wonder what on Earth happened to the DRobbins offer..

The ultimatum? ;) It was withdrawn.

As for Gentoo, I'm on my lookout for another source-based or source-enabled distro, one that doesn't produce horrific breakage every 3 months. I had a working install bail out from under me a month ago.

Every distro requires recompiling for certain ABI breakages. You just don't see it with binaries, so whichever source distro you get will give you the same problem.

I see there have been some discussion as to whether the devs should be concerned with stability or with being up-to-date. It's a shame really to say that they are failing at both at the same time.

I disagree. Gentoo is much more stable than it used to be, so long as you don't run ~arch across the board. It's also as bleeding-edge as it can be imo, eg mysql-5.0.54. Gnome is pita afaics from #-desktop, but kde is pretty up to date. What do you mean?

And while I see that there is a shortage of devs - no surprise really, with all the trolling going on -, at least some of the issues could be solved by prioritization of problems. The main shortcoming of gentoo lies in the ebuild format and portage. With a new repo format - not silly PR activities, like implementing a new signing system and removing per-package Manifests, but REAL redesign from bottom up - we could even be going somewhere. We could have true multilib, for example. No more need for revdep-rebuild, and most of all no more need for emerge -e world, which is the screaming symptom of a fundamentally broken package management system.

Tsk, ABI breakage is unavoidable. There is work going on in portage to handle revdep type situations automatically by tracking libs, but I'm perfectly happy with [topic=546828]update[/topic] picking up any elog/warn/info the ebuild dev might send out about running revdep-rebuild on a lib.
Emerge -e world is only for gcc X.Y.z upgrades where X or Y change, btw.

Of course ebuilds could be kept as a legacy format. First only the core packages would need to be migrated, with the enermous userland left in the old repo, and gradually migrating those too.

Assuming anyone wants to do that by moving to Paludis instead of letting it happen organically within Gentoo.

Speaking of package managers, I find the suppression of Paludis quite comical - it's obviously a personal issue, and personal issues dictating technical conduct is another good reason for getting off the Gentoo bandwagon for good.

Hmm I agree there are personal conduct issues at the heart of the paludis debate. Those do affect technical development however. ciaranm was slung out for repeated offences, aiui, so I don't feel the need to question it anymore. It happened 2 years ago, after a couple of years of obnoxious behaviour. I quite understand why many devs don't want to work with him.

While Paludis doesn't solve all the former problems in itself, it opened lots of pathways that could have lead out of the Gentoo tarpit.
Devs like to comment on it not building all ebuilds. (Makes me think of the Browser Wars of 2000 - of course it was all Netscape's fault, not that of the pages with shitty markup.) Maybe it doesn't. Mostly it's only the test phase that fails because of the sandbox. I wonder if portage runs the test phase by default... If I'm not mistaken, it doesn't.

No it doesn't since many packages are known to fail their tests. How exactly Gentoo is supposed to make upstream comply with that, I don't know. In the meantime it's foolish to run them by default. It also adds a significant amount of time to the build process, and afaic, the portage approach is much better. I can always add test to the use for a package I'm interested in, and if I'm not I just want it to install and work; I can file a standard user bug if it doesn't.

Anyway, Paludis has a way of referencing repositories (and thus masking or unmasking a package by repository), supports several package formats, and handles dependencies correctly.
Sure, it's not the holy grail. It would be a step in the right direction. But sure, it's much more fun poking paludis devs and users around, and defending portage in screaming fits of rage than getting down to work on the ruddy thing.

Sorry you don't know what you're talking about. zmedico regularly consults with pkgcore and paludis devs, and just works on the software. 2.2-pre has just hit tree as well (thanks genone.)
If anyone makes Gentoo development harder, imo it's the paludis team. But that's by-the-by I guess.

And no, removing per-package Manifests is not a step. It's PR. Sand to throw in the eyes of users. "Steps" would have something to do with dependency tracking, the basic underlying logic of package management and such. Heck, even the concept of USE flags would welcome a redesign. They're getting too numerous to handle.

So what would be a better concept (ie a real design change, not just implementation help) than USE flags?

Also did anyone notice that ebuilds have no clean way of declaring "drop-in replacement"? Sure, we have virtual, which is cumbersome and misses the whole point. Say, I have a drop-in replacement for a library not in virtual, like, for example aalib. I can do one of two things: create an ebuild for it under a fake name of aalib and a fake version number something like 9999.1 so it would install and take its rightful place in the deptree, or I can take every single ebuild depending on aalib, and migrate them to depend on virtual/aa, create virtual/aa, modify the aalib ebuild and then I can insert my drop-in replacement. Sounds like a Monty Python sketch, but it's the Gentoo truth. :(

Yeah but that's for a dev to do, not a user, unless you're doing it in your overlay. It's not major is it? I'm surprised paludis doesn't have some script to do it for you.

Also, there is some default behavior that would need a different view at things. Take unicode for example. It's 2008, and Gentoo still doesn't ship with unicode (widechar support) as a default. No, the "unicode" flag doesn't do it. All binary distros come with unicode, but to get unicode REALLY working in Gentoo, one needs to hack away at the ncurses ebuild, cut half of it out, and write some patch code himself. And ncurses is ACTIVELY DEVELOPED, with a really fat ebuild full of ifs and cases. All boiling down to no unicode in two-thirds of ncurses apps. (I guess the English-speaking devs living happily with the ASCII charset don't even notice the problem.) Redhat ships midnight commander with a unicode patch. Gentoo doesn't.

Man again, you just don't know what you're talking about. If you want mc with unicode you also need to compile it with slang, which the ebuild tells you about. As for getting unicode, we had an Italian user having issues in #-desktop. When he finally got through it, I asked him to write up what he needed to do, since he said the docs hadn't helped. A while later, he came back and said it was all in http://www.gentoo.org/doc/en/utf-8.xml (the Italian version ofc.)

All in all, returning to the first statement... Instead of overall stability or up-to date functionality, gentoo seems to revolve around making sure things will go smoothly in certain improbable and never before encountered scenarios, while leaving screaming breakages wide open that people come across and live with day to day and complain about.

Nah it does a damn good job at being both stable, configurable and up to date. If you think it's behind in a certain area help out with it; much of the work goes on in overlays before stuff is moved to the tree. Breakages are fixed by revdep or you should file a bug.

Anyone know of a good source-enabled distro, possibly with corporate backing? :)

As I said, ABI breakages will happen on all of them. Gentoo is by far the most complete and easiest to maintain. You really want a binary distro, or to [post=4716038]use a binhost[/post].

steveL wrote:Every distro requires recompiling for certain ABI breakages. You just don't see it with binaries, so whichever source distro you get will give you the same problem.

This is no doubt true. However with correct dependency handling, ABI breakages could be found and fixed transparently.
My experience is that revdep-rebuild only finds the obvious breakages, when a library does a major version jump. Sometimes a library update would cause strange runtime breakage (instead of a dynamic linking error) that revdep-rebuild can't detect. So with every update you run the risk of breaking something.

No it doesn't since many packages are known to fail their tests. How exactly Gentoo is supposed to make upstream comply with that, I don't know. In the meantime it's foolish to run them by default. It also adds a significant amount of time to the build process, and afaic, the portage approach is much better.

Paludis can also be made to skip tests with a simple environment variable setting. The reason I brought tests up is that it's the source of 99% of so-called "paludis incompatibility".

Sorry you don't know what you're talking about. zmedico regularly consults with pkgcore and paludis devs, and just works on the software. 2.2-pre has just hit tree as well (thanks genone.)
If anyone makes Gentoo development harder, imo it's the paludis team. But that's by-the-by I guess.

Probably. Honestly I stopped following this private war long before. I'm not interested in the saga of Ciaran vs. Everybody else, but one would hope technical matters overcome personal hurts.

So what would be a better concept (ie a real design change, not just implementation help) than USE flags?

In my opinion USE flags could be organized into a tree with top-level flags containing lower-level flags and so on. And they could undergo some standardization, as I think there are just too many "Local" USE flags, sometimes doing the job of an existing global one.

Yeah but that's for a dev to do, not a user, unless you're doing it in your overlay. It's not major is it? I'm surprised paludis doesn't have some script to do it for you.

Well, that's the whole point. Sure it's for a dev to do.
The problem is that when a user wants to use a library not in portage as a drop-in replacement for a lib in portage, he must either badger the gentoo devs into including it and virtualizing the lib (possibly takes ages, possibly they will just refuse it), or he must mirror the entire portage tree into his overlay, resulting in an unworkable system.

Man again, you just don't know what you're talking about. If you want mc with unicode you also need to compile it with slang, which the ebuild tells you about. As for getting unicode, we had an Italian user having issues in #-desktop. When he finally got through it, I asked him to write up what he needed to do, since he said the docs hadn't helped. A while later, he came back and said it was all in http://www.gentoo.org/doc/en/utf-8.xml (the Italian version ofc.)

Oh I know exactly what I'm talking about. I'm talking about 75% of ncurses packages not linking against ncursesw.so. I've filed bugs, patches and ebuilds for ncurses, and have also taken part of some discussion of what should be done. What works for me is building ncursesw only, and symlinking it to ncurses.
The portage tree version doesn't work the way I expect. In the end my claim was refuted with that this is not an issue, and the ncurses-based programs should be made aware of ncursesw.so. Well, I've yet to see any of them "made aware".
Most interesting though, several major distributions are living happily ever after having ncursesw only.

Nah it does a damn good job at being both stable, configurable and up to date. If you think it's behind in a certain area help out with it; much of the work goes on in overlays before stuff is moved to the tree. Breakages are fixed by revdep or you should file a bug.

Revdep fixes some breakages, not all. As for filing bug reports, I've been quite active on that field, and if I could pinpoint one, I filed it.

Simius wrote:

steveL wrote:Every distro requires recompiling for certain ABI breakages. You just don't see it with binaries, so whichever source distro you get will give you the same problem.

This is no doubt true. However with correct dependency handling, ABI breakages could be found and fixed transparently.

Hmm I have to say I agree with you; one thing that I've always found crazy is that there's no LDEPEND (link-dependency or lib if you prefer.)

Sorry you don't know what you're talking about. zmedico regularly consults with pkgcore and paludis devs, and just works on the software. 2.2-pre has just hit tree as well (thanks genone.)
If anyone makes Gentoo development harder, imo it's the paludis team. But that's by-the-by I guess.

Probably. Honestly I stopped following this private war long before. I'm not interested in the saga of Ciaran vs. Everybody else, but one would hope technical matters overcome personal hurts.

That's not the issue imo; the issue is whether you can work with someone. It's fine to work off in a corner on your own; it's quite another to make it impossible for others to do the same. I only brought it up as you implied the portage devs behave badly instead of fixing portage, which is totally untrue.

So what would be a better concept (ie a real design change, not just implementation help) than USE flags?

In my opinion USE flags could be organized into a tree with top-level flags containing lower-level flags and so on. And they could undergo some standardization, as I think there are just too many "Local" USE flags, sometimes doing the job of an existing global one.

I don't see the real benefit in a tree of USE flags. Sets, maybe, but I think profiles fulfil that. As for decrufting, no argument.

Yeah but that's for a dev to do, not a user, unless you're doing it in your overlay. It's not major is it? I'm surprised paludis doesn't have some script to do it for you.

Well, that's the whole point. Sure it's for a dev to do.
The problem is that when a user wants to use a library not in portage as a drop-in replacement for a lib in portage, he must either badger the gentoo devs into including it and virtualizing the lib (possibly takes ages, possibly they will just refuse it), or he must mirror the entire portage tree into his overlay, resulting in an unworkable system.

IDK I'd just use package.provided for the portage lib, and compile the other one myself. I accept it would be a bit trickier if you wanted that as an ebuild which was updated, but I don't think you really need to mirror the whole tree do you?

Man again, you just don't know what you're talking about. If you want mc with unicode you also need to compile it with slang, which the ebuild tells you about. As for getting unicode, we had an Italian user having issues in #-desktop. When he finally got through it, I asked him to write up what he needed to do, since he said the docs hadn't helped. A while later, he came back and said it was all in http://www.gentoo.org/doc/en/utf-8.xml (the Italian version ofc.)

Oh I know exactly what I'm talking about. I'm talking about 75% of ncurses packages not linking against ncursesw.so. I've filed bugs, patches and ebuilds for ncurses, and have also taken part of some discussion of what should be done. What works for me is building ncursesw only, and symlinking it to ncurses.
The portage tree version doesn't work the way I expect. In the end my claim was refuted with that this is not an issue, and the ncurses-based programs should be made aware of ncursesw.so. Well, I've yet to see any of them "made aware".
Most interesting though, several major distributions are living happily ever after having ncursesw only.

OK: I don't know what I'm talking about then :D

The more interesting question to me is whether Gentoo represents the logical end point of the 'source-centric' Linux distribution model (ie. it can't get any better than this). Is Gentoo the pinnacle of the source-centric concept? If not, how can the concept could be taken further? What does that look like? Those are the hard targets I'm interested in.

My insignificant opinion is that Gentoo should steal a little more from BSD. It worked earlier BSD is the current pinnacle of the source-centric concept. IMO the way to address the stability vs. up-to-dateness problem would be to adopt the "rock-stable base system, optional stuff on top of that" idea that FBSD has. Just make the system profile really, really stable, and advertise updating system instead of world. Possibly provide binary packages for System only.

Sync and update system twice a year, unmask optional packages on top of that when desirable. You could even get rid of the stable/unstable crap because System would be stable by definition. World could be as crazy as you want. You could get rid of releases, too. They don't mean anything anyway. Stop selling CDs, upload install ISOs twice a year, done.

Wouldn't this be more manageable?

Other ideas for hard targets:

- Integrate equery, glsa, esearch, revdep into emerge
- Document USE flags better
- Make it easier to update config files
- Simplify and accelerate the init system
- Merge many small config files into fewer big ones (rc.conf style)

Those are my 2 cents.

I don't subscribe to the "Gentoo is dying" hype though. Hard targets, yeah.

Sprotte wrote: Other ideas for hard targets:

- Integrate equery, glsa, esearch, revdep into emerge
- Document USE flags better
- Make it easier to update config files
- Simplify and accelerate the init system
- Merge many small config files into fewer big ones (rc.conf style)

I would not agree to the last item; in fact, one of the things I like about Gentoo is that the config files are often as close to the standard ones as possible. This having said, one of the goals could be to get the best out of the symbiosis "easy manageable" and "as standard as possible".

However, I fully agree with the rest of what you are saying - especially documentation of the USE flag and the config updates seem a pain now...

tkhobbes: Which standard are you referring to? Is there a standardised Linux rc file layout?

I meant the stuff in /etc/conf.d especially, several of those files just contain one or two lines! FBSD for example has just about two or three system wide config files, the main one being rc.conf which contains just that conf.d stuff. The advantage is that every server admin setting up a BSD system has the important shit in just one file. Gentoo's rc.conf has been castrated over the years.

If Gentoo's layout conforms to some GNU/Linux standard, that's something else then...

I meant the config-files of all the different programs around - they all have standardized formats, placed and meanings and "ways they should be like". What I never liked about SuSE for example is the idea of the overall config-file that sometimes lead these standardized ideas ad absurdum.

I don't know much of init-scripts and can't judge on what is useful there or not - however, as far as I can tell, Gentoo's way of handling it is not exactly as it initially was meant to.

Being a "user" rather than a "geek", I sometimes struggle to understand what I have to do when something is not working. Part of this is that I often find answers, but as every Linux distribution implements stuff a little bit different, everything gets difficult. This is what I mean. To put it simple: What about being Gentoo set up in such a way that every "general how-to" can be applied without making changes? That whatever I read on programs' and projects' websites is adhered to?

IMO Gentoo initscripts have always been a real selling-point. They're much nicer to configure than any other distro, and OpenRC (the initsystem formerly-known-as baselayout2 ;) looks very quick too.

Wrt file layout check out the FHS which is pretty much how Gentoo does things afaict. (Personally I think /usr/etc should come back.)

OK, but the FHS doesn't say anything about /etc/conf.d/* and /etc/env.d/*. I just think that the amount of files in /etc should be reduced. My /etc after several years is a mess. I am 90% sure about what I can delete (config_protect...), but not always 100%. IMO config_protect needs to go in the long run, because it pushes a load of problems upon the user, and Portage needs to get more intelligent with config files. Less config files would help.

/usr/(local)/etc, yeah, that's one way to do it - keep obscure third-party config files seperate from the system ones. Keep all third-party stuff seperate from system, for that matter.

OpenRC might be better, but it follows the same conventions (so it says) and thus the configuration side of it doesn't change. I find 29 seconds on a modern machine still rather slow, btw. OK, let's not talk about Windows.

My biggest practical problems with Gentoo are:

- devoting hours to upgrade between minor versions of GCC etc. (idiotic)
- updating /etc files (tedious, and most of them should be handled by Portage)
- missing features in emerge (have to read forum and use addon tools)
- new USE flags that are either cryptic, badly documented, or both
- fragmented system configuration (it's in too many places)

Now, don't look at this as "dissing"; I still think Gentoo is the best Linux distro in existence. I've just learned that "all operating systems suck, Gentoo just sucks less."

I keep using it because we're a winning team, and because I learned where its shortcomings are and how they're typically dealt with. Still, often it feels like a three-legged horse. The problem is not incompetent developers; the problem is a lack of vision and consequence. Bloat accumulates.

Gentoo should not care so much about which version of beta quality desktop environments goes into portage. There can be overlays for that. Gentoo should care more about breakage in the system profile, and improving the central tools.

Sprotte wrote:- updating /etc files (tedious, and most of them should be handled by Portage)

it is called 'dispatch-conf', if you aren't using it for config file updates you're doing it wrong (just using the internet meme not being snotty).

as for your other conf issues, you're criticisms (or perspective) is lot on me.

Sprotte wrote: /usr/(local)/etc, yeah, that's one way to do it - keep obscure third-party config files seperate from the system ones. Keep all third-party stuff seperate from system, for that matter.

Well seeing that portage should never install anything to /usr/local/ im struggling to see what your on about. We can't control stuff not in the tree.
Also as a little rant, users should never unpack/manual install stuff to /opt they should put it in /usr/local/opt

Sprotte wrote: My biggest practical problems with Gentoo are:

- devoting hours to upgrade between minor versions of GCC etc. (idiotic)

And here was me thinking that gentoo was a source based distro....

Sprotte wrote: - updating /etc files (tedious, and most of them should be handled by Portage)

They are handled by portage. and in the best way possible too. Would you rather have portage just overwrite your (modified) configuration files. We provide tools to manage the update of configuration files.

Sprotte wrote: - fragmented system configuration (it's in too many places)

mmm... can't agree.
/etc/* Most are also in nice directories for you too.
for each /etc/init.d/${1} edit /etc/conf.d/${1} // ok /etc/init.d/net.* is one exception, but not much of one.

Are you referring to the lack of a central configuration gui based tools?

alistair wrote: Well seeing that portage should never install anything to /usr/local/ im struggling to see what your on about. We can't control stuff not in the tree.
Also as a little rant, users should never unpack/manual install stuff to /opt they should put it in /usr/local/opt

The background was my opinion that Gentoo should enforce a system/world split like FreeBSD's base/ports one. System should contain all the mission-critical things and be stable by definition (= you could not have ~x86 things in system.) Only their configs would go to /etc then, everything else to /usr/(local/)etc.

- devoting hours to upgrade between minor versions of GCC etc. (idiotic)

And here was me thinking that gentoo was a source based distro....

So is BSD, but you never compile gcc unless you want to. IIRC it isn't even in Ports. The background is the same as above. Seperate system and world. Let only major gcc/glibc updates go into stable, perhaps twice a year.

- updating /etc files (tedious, and most of them should be handled by Portage)

They are handled by portage. and in the best way possible too. Would you rather have portage just overwrite your (modified) configuration files.

No, I'd rather have Portage detect where I changed default configs, assume I want to keep those changes, and merge my changed lines into the new version automatically. Exactly like a dispatch-conf that automatically picks the left (old) option, just as part of Portage.

It would only ask about changes it somehow cannot resolve, for example if there is a new option.

Then give emerge a switch that enables the old behaviour, for the masochists.

We provide tools to manage the update of configuration files.

I think having the user do all of this is only a workaround for missing functionality in Portage. Turning a problem into a feature.

Sprotte wrote: - fragmented system configuration (it's in too many places)

mmm... can't agree.
/etc/* Most are also in nice directories for you too.
for each /etc/init.d/${1} edit /etc/conf.d/${1} // ok /etc/init.d/net.* is one exception, but not much of one.

I'd like to see the whole thing super-simplified into just a handful of text files. I'd like 3 long files better than 30 short ones that contain just two lines, one of which is a comment.

Question of taste, though.

Sprotte wrote:I'd like to see the whole thing super-simplified into just a handful of text files. I'd like 3 long files better than 30 short ones that contain just two lines, one of which is a comment.

Question of taste, though.

There are technical reasons for using multiple smaller files instead of a few large ones:
1) it's much easier to drop a new file into a directory than modifying an existing file, esp. with user-controlled files. This is even more important when a file is used by multiple packages.
2) Limiting scope of configuration settings: Sometimes you need one variable to have different values for different applications which isn't possible with one large config file usually. It's also better if applications only see the variables that are relevant for them to minimize possible side-effects.

Mind I'm talking about the general case here, so it's possible that my arguments don't match your specific case.

Sprotte,

We could have one large configuration file and call it /registry

Hmm - its been tried and shown not to work too well.

kindly review the following thread:

http://forums.gentoo.org/viewtopic-t-675422.html

I'm getting hundreds (if not thousands) of those error (currently digesting the whole portage-tree )

whose idea was that ?

HELP ?!

(just finished, but this won't taste good for newbies )

I'm pretty sure that there was an ewarn output when you updated portage that tells you what you need to do to prevent that error...

I just don't remember what it was that it told me to do. Anyway, I followed the provided instructions and didn't run into the issue that you have.

Time to start looking through the portage ebuilds for ewarn messages I think.

Edit: found it

echo "If you have an overlay then you should remove **/files/digest-*" \
"files (Manifest1) because they are no longer supported. If earlier" \
"versions of portage will be used to generate manifests for your overlay" \
"then you should add a file named manifest1_obsolete to the root of the" \
"repository in order to disable generation of the" \
"Manifest1 digest files."

It would appear that the issue only arises if you use a portage overlay. I do, but it only has 3 ebuilds in it and I manually updated the digests for them as instructed.

Edit2: Perhaps you have not upgraded portage after your last sync and that is causing the issue?