What do you NOT like about Gentoo?

[nirax]

I don't like how long things take to enter the stable branch. Lets all keep using firefox2!

i second that. especially for amd64 its still - or again, if you like - a joke especially for security sensitive applications. It would be interesting to have a distro chart showing how long it takes (per arch) until lets say an exploit fixed firefox is released.
edit: actually it seems i was not the only one with the idea.. package freshness gets monitored in distrowatch, and here is the gentoo-dev thread about.. http://www.mail-archive.com/gentoo-dev% ... 35813.html
My favored comments come from Ryan basically exactly bringing to the point what anoys me about Gentoo attitude 2009

..actually im on the way backupping my private data to move on after over 5 years of gentoo. For me thats no longer acceptable. I understand that i should contribute to make it better, and so on.. I have unfortunately no time for it and other passions in my free time, so i plan to move also this (ex main comp) on a full support distro.

All other systems (netbooks, notebooks and servers in the house) already run since their set-up time on another distro, but this ex. main system in my home-office room runs since i assembeled it early 2006 with the same gentoo installation
(updated until early 2009, when i started to get bored (maybe lack of "gentoo-skill") to sort or get time for all these emerge blocker errors).

..the system runs as much as its possible wihtout completely comromising security as pure "stable" version.

not sure if i overcome my lets say "sentimental feelings" and really move on with this system .. but the "annoyance" and "bored-of-problems level" raised in the last years and is at least on pair with what was once love

so to add some other super-annoyances for me

• - gentoo-dev politics
  - lack of ideals since DR left (interesting DR blog post http://blog.funtoo.org/2007/07/so-can-i ... -back.html )
  - package.unmask/package.keywords instead being able to force install
  - requiring to use package.keywords and unmask to install latest version of security fixed applications because gentoo got to slow (its a distro criticism, i fully understand the developer/QA situation and that you guys are already doing your best. You may just need more people, or concentrate on the more important apps first.
  - blockers and blocker handling. Never ever had that hard time upgrading other linux or freebsd systems running on stable or whatever branch.
  - emerge --sync / eix-sync speed *YAWN*
  - slowness of packages entering the tree (was also already named, but i second that too, leading to some self compiled and self maintained stuff on the system..)

edit: one_more_quitted_for_ubuntu++

[regomodo]

My views are very similar to nirax.

• developer politics
  Slow additions to portage. Rarely is it bleeding edge.
  emerge --sync speed
  emerge operations are slow

[energyman76b]

for all you people moaning about blockers:

a) portage 2.2 handles blockers very well

b) if you think other distris don't have that problem - be prepared for some nasty surprises.

[energyman76b]

My views are very similar to nirax.

• developer politics
  Slow additions to portage. Rarely is it bleeding edge.
  emerge --sync speed
  emerge operations are slow

emerger --sync takes 150seconds. Is that really that long? Two and a half minutes?

[nirax]

there are problems with other distros too. sure, like with every os.
but specific portage and dependency problems are for long time known now. more or less recognized help is available through other package managers in development (like paludius) but the current standard state can still break too easy. (must not, but can)
read gentoo-dev threads regarding portage back to 2004 and you will notice that its a known problem. the thing is that all in one for me the annoyance level got too much.

to quote from the paludis dev site and George Makrydakis interview, basically reflecting Ciarans statement, which of course comes from a competitor product, but still sums up apparently relatively well what a large part of ppl think of portage (just search gentoo-dev for portage or EAPI and read back in time)

The Portage codebase is too broken to be fixed. It is a huge mess of spaghetti procedural code with no underlying design. It relies upon weird quirks in its own behaviour all over the place, so any change is liable to cause huge breakage in seemingly unrelated areas. It is almost entirely undocumented, and the internal names are perverse and often do not reflect what the code now does.
..
The idea of flat out replacing Portage built up over time as more and more easy, useful and necessary features weren't being added to Portage, either because the Portage codebase was too messy to allow it or because there was a massive shortage of qualified people who were prepared to go near it.
..
There are also issues with how EAPIs are specified. EAPI is set by a variable in the ebuild itself, which limits changes that can be made. It isn't possible, for example, to define a new version suffix in an EAPI, nor is it possible to change the behaviour of 'inherit' or add new global scope functions. Paludis has ways of working around this by using EAPI-suffixed file extensions; unfortunately it was deemed too difficult to make this work with Portage.
..
In terms of future direction, there're a few people experimenting with a new ebuild-derived package format known for now as 'exheres'. Exheres is billed by some as "ebuilds redesigned with ten years of experience". At the very least it's a way for people to experiment with proposed new EAPI features before anyone puts in the huge amount of work that it'd take to add them to Portage.

and the emerge --sync speed test.. well if that should be now a general performance statement, sorry please never search a job in a QA department (just kidding. nice that it runs fine for you)
regarding emerge2.2 ..good to hear that there comes improvement. but if i remember right it is in the main branch of Funtoo, but still marked unstable ~amd64 in gentoo.

anyway most important though is that the thread topic is named "what do you NOT like about Gentoo". so its just a personal subjective productive hint, neither bashing nor anything else, so im not sure what sense it would make to debate pro/con or "works for me" on every point in here.
most productive could be to make at some point a sheet (by the appropriate user-rel or forgot-what-it-was-called) out of this input, pick up the points and weight them in order to create a plan or at least an overview about the biggest user annoyances or if you like otherwise, call them misunderstandings. - the problem (and here comes the point about politics and endless dev debates and fights) is for me more that i do not think any of these points are really new, unknown or overlooked.

[chris...]

My views are very similar to nirax.

• emerge --sync speed
  emerge operations are slow

emerge --sync takes 2-2.5 minutes depending on how much is added, it would be much quicker, like 45seconds but i use an sql database cache that gets updated for every sync, this makes emerge operations fairly quick

[Ormaaj]

All of my criticisms are relatively minor. I love Gentoo and couldn't imagine using anything else.

My one issue is the number of packages which simply fail to compile. I run several fairly standard instillations on fairly standard hardware and archs. I don't understand how so many common packages make it into the tree, unmasked, if they don't even compile without error. Sometimes the issues aren't resolved for months at a time.

Runtime errors are quite rare by comparison. The frequency of compile problems independent of my configuration makes me thing that virtually zero testing goes in before version bumping. I run -O3, but thats usually not the problem.

And yes the usual nag about package.keywords/unmask. Its really not THAAT bad. One thing is i wish portage could recursively figure out every block, unmask, and keyword error instead of having to append the files repeatedly and retry emerge over and over. That tedious process sometimes has to be repeated 10 or 20 times in order to unmask lots of dependencies. Writing a script to automate the process is NOT the answer. Theres no excuse for portage not having that feature.

Ebuilds should be easier to write. The learning curve is unnecessarily steep.

[energyman76b]

hm, I run a pretty unstable system and I run rarely into compilation problems - and most of the time it is caused by some breakage that is easily fixed by revdep-rebuilt

[Bill Cosby]

Ebuilds should be easier to write. The learning curve is unnecessarily steep.

Dito.

I am wondering, the best packaging format I have ever encountered is the BSD derived system used by Crux (It is so great, just thinking about it makes me want to use Crux again, if it weren't for some poor choices about their core system etc.)
Anyways, you basically write a script to handle the downloaded package, technically it doesn't matter in which language, however, for standard purposes, and for low system requirements, it is usually written in a POSIX compliant shell language, and then install it (make install) with a package system specific location, there you can do some cleanup operations, and the packaging system will then copy the files to your system and index them to easily get rid of them later on.

The packages are totally transparent and easily understood, this is their advantage, yet, they have to be, because you basically have to directly alter them, to get the same behavior as use flags, that's their disadvantage.
Still, due to their simple nature, I could write 20 packages a day, yet, until now I haven't finished even one ebuild, and every ebuild I see makes me confused, rarely can you easily see what is really going on. To really understand ebuilds, it demands some deep interior knowledge of the portage system, which is Spaghetti in every aspect, and needs to be reworked as soon as possible, without the fear of loosing compatibility.
This is the greatest problem in Gentoo ebuilds, past errors are kept, simply to make (soon to be) past packages work. A new sane system would demand rewriting every ebuild, so they don't want to advance, but rather stay in their error ridden design, which in itself is natural law, design is always error ridden, however, after years of experience, one has to have the courage to destroy the old tables, and create new ones.

Regards.

[Hypnos]

To really understand ebuilds, it demands some deep interior knowledge of the portage system, which is Spaghetti in every aspect, and needs to be reworked as soon as possible, without the fear of loosing compatibility.

Could you not just read this?

This is the greatest problem in Gentoo ebuilds, past errors are kept, simply to make (soon to be) past packages work. [...]

Please give examples of backward compatibility that you find troubling.

There is a brief summary here.

[Bill Cosby]

Could you not just read this?

What do you mean with "just"?

Please give examples of backward compatibility that you find troubling.

What I meant is that a new, reworked ebuild style, will never be introduced, because present packages would be obsolete then.
I am referring to the whole ebuild design. After the experience which was gathered with ebuilds, I'd say one could come up with something better, more simple.

[Hypnos]

What simplifications do you propose over the current ebuild standard as described in the devmanual?

Alternatively, please describe why -- exactly -- crux ports are better.

[Bill Cosby]

What simplifications do you propose over the current ebuild standard as described in the devmanual?

Neither do I know the dev manual, nor do I have vast experience with ebuilds. All I know is that ebuilds, and portage, are highly complex and complicated, and I do not believe this is out of necessity, but due to bad design. I would like to see the the UNIX approach implemented, instead of creating one giant, bloated, parsing system for ebuilds.
By definition, this would make things more simple.
Yet, I understand that as long as people use something like autohell in their packages, it is much tougher to come up with sane package management.

Alternatively, please describe why -- exactly -- crux ports are better.

It is more simple, easy to understand, and very transparent.

[Hypnos]

What makes crux simpler than Portage? In doing so, what capabilities is it lacking, if any?

So far, your argument is "Portage is too complicated even though I haven't read the devmanual, crux is awesome even though I won't describe it and can't be bothered to compare and contrast."

[disi]

I just started reading here, actual the distro does look very nice. Per default it had no dependency check for example:

"4.3. Package management frontend: prt-get

To address the different requirements towards package management in CRUX, a number of users started discussion about an advanced package management frontend to pkgutils, with dependency handling and support for large install transactions. The result of this community effort is prt-get, a tool which provides a number of features on top of pkgutils while keeping pkgutils' original character and power. Its main features are

* Dependency handling
* Build logging
* Powerful search and query functionality

Nowadays prt-get is an official project and tool of the CRUX project.

A full description can be found in the manual of prt-get. "

This would be the users based packageing system. Here is the quickstart guide: http://jw.tks6.net/files/crux/prt-get_quickstart.html I think it is not better or worse than emerge.

Creating a package seems straight forward and as he mentioned it is simple BASH:
"To be more specific, the Pkgfile file is actually a bash(1) script..." http://crux.nu/Main/Handbook2-6#ntoc6

make.conf = editing the pkgmk(8) configuration file /etc/pkgmk.conf.

ports is 1:1 BSD it looks like: http://crux.nu/Main/Handbook2-6#ntoc6

contrib collection = layman http://crux.nu/Main/Handbook2-6#ntoc6

//edit: for the use of ports they have a little the system like rpm, a file in /etc/ports where the settings for each respository are stored.

//edit: http://crux.nu/portdb/ here is a list of available ports, while only core and opt are official (the others are like layman). You click on the like called "ports" at the top of the page and get a list of "repositories"

//edit: only i686 support...

//edit: you can define compiler flags and directories in the /etc/pkgmk.conf, no USE flags?

[Bill Cosby]

What makes crux simpler than Portage?

I already explained it in my response to Ormaaj.
You basically just write a script to handle the downloaded package, as you would do without a package manager. No magic behind the scenes, everything that is done can be seen in your script (and they still have less loc than most ebuilds).
No need to use bash, or python.

In doing so, what capabilities is it lacking, if any?

Unix philosophy is about communicating over standard I/O, so any language can be used to write your script/program. E.g. the ebuild script could simply put necessary data to stdout, and a parsing program can build a dependency tree accordingly. Another program should handle installation, keeping track of the files installed, etc.
There should be no need to import svn, or patch modules.
"Write programs that do one thing, and do it well" - D. McIlroy

So far, your argument is "Portage is too complicated even though I haven't read the devmanual, crux is awesome even though I won't describe it and can't be bothered to compare and contrast."

Crux's ports is not awesome, it sucks. It lacks the necessary tools to make it a real package management, however it is simple, which makes it suck less. They don't have the right Unix approach either, yet, have good ideas, nevertheless.
Portage's use flags are a very good idea to customize packages, yet, I am simply not convinced it is implemented in a sane way.
E.g. the whole concept of RDEPEND seems flawed. Which program even must have a certain program at runtime, it didn't need at build time?
In general, the tendency towards bloat within Linux is scaring me.

edit: Crux has many shortcomings, I am not happy with, it seems their lack of success even made them follow the bloat approach.
Gentoo is overall the better distro. However, some of their approaches are very refreshing and I would like them to see in Gentoo as well, e.g. http://crux.nu/Main/Handbook2-6#ntoc29

[Hypnos]

You basically just write a script to handle the downloaded package, as you would do without a package manager. No magic behind the scenes, everything that is done can be seen in your script (and they still have less loc than most ebuilds).

It is probably easier to write a custom script for each package, but without code reuse maintainability becomes a nightmare. This where a standard interface, eclasses and common ebuild utilities come in.

No need to use bash, or python.

Then what do you write the script in?

Anyway, Python has nothing to do with ebuilds. emerge happens to be implemented in it, and Paludis is written in C++. The ebuilds are based in bash.

Unix philosophy is about communicating over standard I/O, so any language can be used to write your script/program. E.g. the ebuild script could simply put necessary data to stdout, and a parsing program can build a dependency tree accordingly. Another program should handle installation, keeping track of the files installed, etc.

This provides a lot of flexibility for one-off scripts, but provides weak interface support when the effort has to be duplicated many times. In other words, how do you know what in what format to put data to stdout?

E.g. the whole concept of RDEPEND seems flawed. Which program even must have a certain program at runtime, it didn't need at build time?

Well, more often there are things you need at compile time you wouldn't need at runtime (e.g, a special build utility like scons) so you distinguish DEPEND from RDEPEND.

And if the software is written in a language with dynamic binding (e.g., Objective-C) there may be many things you might need at runtime which you wouldn't need at compile time.

***

My overall message is that Portage is a mature technology being improved by having a written and vetted ebuild specification and by having competing package managers. You need to be specific in describing possible shortcomings in this architecture and how alternatives are superior. I have yet to be convinced that the Crux approach gains anything, and as I have argued it may have some serious drawbacks which are addressed by Portage.

[Bill Cosby]

It is probably easier to write a custom script for each package, but without code reuse maintainability becomes a nightmare.

Common, and repetitive tasks will evolve into small programs which automate, and optimize the given task, and can be easily integrated (std I/O), that is the UNIX approach. And a perfect example of "code reuse" (libraries are another, but here, too, it should be: "do one thing, and do it well")

Then what do you write the script in?

Technically, it doesn't matter, as long as you can utilize std I/O, however, as I said, ideally it would be a POSIX shell.

Anyway, Python has nothing to do with ebuilds.

Python is not that bad anyways

This provides a lot of flexibility for one-off scripts, but provides weak interface support when the effort has to be duplicated many times. In other words, how do you know what in what format to put data to stdout?

Through specifications. You document what your program expects. Where do you see the problem?

Well, more often there are things you need at compile time you wouldn't need at runtime (e.g, a special build utility like scons) so you distinguish DEPEND from RDEPEND.

Is this some kind of "possible future feature" then? Meaning, that it has presently no meaning, but there might be a future implementation, like removing build dependencies after the built?
Or what is it currently used for exactly? E.g. can I somehow remove the built dependencies, while keeping the run dependencies?

And if the software is written in a language with dynamic binding (e.g., Objective-C) there may be many things you might need at runtime which you wouldn't need at compile time.

Interesting, I will look into it, before commenting.

My overall message is that Portage is a mature technology being improved by having a written and vetted ebuild specification and by having competing package managers.

In programming, the data structures are key to the code, a simple data structure will spawn simple code.
The ebuild system reminds me of XML, which in itself is also mature and stuff, yet, I dare to say it is used for some of the greatest abominations of software design ever:
http://dataspora.com/blog/xml-and-big-data/
http://doc.cat-v.org/xml/the_case_against_XML.pdf
http://c2.com/cgi/wiki?XmlIsTooComplex

"The essence of XML is this: the problem it solves is not hard, and it does not solve the problem well." -- Phil Wadler, POPL 2003

Anyways, different topic, however, the point is that sometimes people clinche too much to their new toys, and overdo.

You need to be specific in describing possible shortcomings in this architecture and how alternatives are superior.

The shortcoming is it's unnecessary complexity. Every problem that arises can be traced back to this very circumstance.

[Hypnos]

Bill Cosby,

* UNIX way versus API way

If you use many small tools but adhere to a specification (e.g, Crux), what does that buy you over having an API where you use some standard tools, set some variables and override some methods (e.g., Portage)?

Perhaps flexibility, but also a lot of wheel-reinventing for common tasks. The idea of Portage is to standardize all common tasks to prevent coder error and enhance maintainability in a collaborative environment -- more intricate, but more efficient overall.

The real test would be if Crux were to ever become as big as Gentoo, whether it would bog down due to these issues ...

* When DEPEND is a proper superset of RDEPEND:

Indeed, currently neither emerge or Paludis calculate the build-only dependencies as unused after a package is installed. AFAICT, this is just due to poor ebuild writing practices and not wanting to cause breakage with existing ebuilds. If this were enforced from the beginning it probably wouldn't be an issue.

* When RDEPEND is a proper superset DEPEND:

For an example of RDEPEND for dynamic binding, see dev-python/matplotlib. Another case is when a package depends on an executable which it calls at runtime rather than depending on a library which it needs at link-time, such as gnustep-apps/displaycalibrator.

In principle when you build binary packages it only needs the build dependencies and not the run dependencies, saving time/bloat. Paludis does not currently support binary packages so I can't test it, and I don't know how emerge handles this ...

* The bottom line

Can you provide some examples where the intricacy of the ebuild API has led to bugs?

[Bill Cosby]

* UNIX way versus API way

It's not versus, libraries can, and should, function the UNIX way as well.

If you use many small tools but adhere to a specification (e.g, Crux), what does that buy you over having an API where you use some standard tools, set some variables and override some methods (e.g., Portage)?

Simplicity, what you don't need is absent in your application.

Perhaps flexibility, but also a lot of wheel-reinventing for common tasks.

I doubt. What do you have in mind.

The idea of Portage is to standardize all common tasks to prevent coder error and enhance maintainability in a collaborative environment -- more intricate, but more efficient overall.

Standards are not a bad idea in general. Nor are enforced standards. However, standardizations should be enforced for data structures, not data algorithms.
If a program only works if you do exactly as you are told to, than there is something wrong, inter-communication should be independent thereof.

The real test would be if Crux were to ever become as big as Gentoo, whether it would bog down due to these issues ...

They already left their path it seems, I am not amused.

Indeed, currently neither emerge or Paludis calculate the build-only dependencies as unused after a package is installed. AFAICT, this is just due to poor ebuild writing practices and not wanting to cause breakage with existing ebuilds. If this were enforced from the beginning it probably wouldn't be an issue.

What is the consequence of this state of existence? Would it even be advisable to remove built dependencies?

For an example of RDEPEND for dynamic binding, see dev-python/matplotlib. Another case is when a package depends on an executable which it calls at runtime rather than depending on a library which it needs at link-time, such as gnustep-apps/displaycalibrator.

The question is why a package manager should differentiate between run and built dependencies in this case. What is the purpose, what is the advantage?

Can you provide some examples where the intricacy of the ebuild API has led to bugs?

The overlays are full of such examples.

[Hypnos]

Standards are not a bad idea in general. Nor are enforced standards. However, standardizations should be enforced for data structures, not data algorithms.
If a program only works if you do exactly as you are told to, than there is something wrong, inter-communication should be independent thereof

Flexibility to do your own thing is nice, but only when it is necessary. If it is not necessary, then maintainability is made more difficult without benefit.

Portage give you both. For example, GNUstep ebuilds are often just a few lines because GNUstep itself is uniform and the eclass takes care of nearly everything; conversely, you can override any and all methods for particularly kludgy software.

I think it's a good idea to take advantage of uniformity when it is there. Have a standard interface and use eclasses to maximize code reuse, rather than merely have a standard interface.

What is the consequence of this state of existence? Would it even be advisable to remove built dependencies?

The only consequence is a little bit of bloat. Assuming ebuilds are properly written, the only problem with removing build dependencies is that you may find that you need them again later.

However, any oft-used build dependencies should be listed in the system profile.

The question is why a package manager should differentiate between run and built dependencies in this case. What is the purpose, what is the advantage?

If you want to build binary packages for later distribution you don't need runtime dependencies. If you have peculiar build-time dependencies, you might not want them hanging around your system after you have finished installing a package.

Can you provide some examples where the intricacy of the ebuild API has led to bugs?

The overlays are full of such examples.

If these bugs exist in the overlays but not in the main tree, it suggests that the learning curve is a problem between users who wish to contribute and official devs.

However, the system should only be as simple as it can be, and no simpler. Since official devs do the vast majority of the work, their maintainability concerns should trump concerns by non-devs about the steepness of the learning curve.

[Bill Cosby]

Flexibility to do your own thing is nice, but only when it is necessary. If it is not necessary, then maintainability is made more difficult without benefit.

If this kind of flexibility leads to simplicity, then the resulting increase in maintainability (due to simplicity) is the aforementioned necessity.

Portage give you both. For example, GNUstep ebuilds are often just a few lines because GNUstep itself is uniform and the eclass takes care of nearly everything; conversely, you can override any and all methods for particularly kludgy software.

That is nice, but I don't understand how this relates to what has been said.

Have a standard interface and use eclasses to maximize code reuse, rather than merely have a standard interface.

As I said, in UNIX philosophy, heavily performed tasks will evolve into a program, that atomizes and optimizes the given task.
The idea to provide libraries for this is not the problem, nor my point of attack, the problem is the bloat, the "do many things and do it badly" approach of most modern libraries.

Assuming ebuilds are properly written, the only problem with removing build dependencies is that you may find that you need them again later.

When do you think we could "assume" this?
That is already the very problem, a feature is implemented which runs under a future assumption, but experience shows that 99,999999% of such "future assumptions" are wrong.
The evolution of a program is distorted, you will carry waste that has no selective pressure, speaking in a biological analogy.

If you want to build binary packages for later distribution you don't need runtime dependencies.

You are propagating a build without a test .. for distribution? This all seems like unnecessary bloat to me, even when ebuilds would be written correctly. However, I have no problems with features per se, so if it is good use, then, well, go ahead.

If these bugs exist in the overlays but not in the main tree, it suggests that the learning curve is a problem between users who wish to contribute and official devs.

That was the original point, I didn't say it is impossible to learn about ebuilds.

However, the system should only be as simple as it can be, and no simpler.

There is a difference between complexity and complicatedness, large systems are bound to be complex, but must not be complicated, or the design is flawed.

[Hypnos]

I agree that unnecessary complexity just becomes complicatedness.

So far, we have discussed only one bit of possible complicatedness in Portage, which is DEPEND/RDEPEND/PDEPEND. (You raise a good point that, in principle, RDEPEND should always be a subset of DEPEND for testing purposes.)

Do you think Portage is bloated? If so, please be specific, and give more examples! Then we can discuss those, and have a better understanding of how Portage may have a poor design philosophy.

[desultory]

(You raise a good point that, in principle, RDEPEND should always be a subset of DEPEND for testing purposes.)

Testing is not necessarily involved in installing any package, indeed building a package is not a requirement either. Packages can easily be pulled from a build host, in many cases even tested on the build host.

[alfagamma81]

Well.. Sometimes when I'm not really in mood "to fix anything", usually problems emerge(not anything that couldn't be fixed though)..