Congratulations and well done.

As we can all see Gentoo is still not perfect. *sigh* Never will be. It should always be a work in progress.

As such I should like to from a users perspective suggest some things that might help.

There should be more AI available to users from a default system. Package managers have been discussed of course. Having run recently a Ubuntu system I was impresssed with some things like synaptics and the janitor. It would be nice to see some cli scripts that help make some good default choices.

A supervisor not a daemon but something that could parse a few logs and make recommendations if needed. Choose a default profile and tweak it for the users intended use. Herds could be utilised to add a recommended install extending perhaps the concept of profiles. In this way a default LAMP install for a VPS Host or server environment could be configured with one extended profile will a kde education server could be another perhaps incorporating some features from overlays?

I also wonder at the "system" definition. Seems somewhere along the line that was determined to be a build environment?

Always been a peeve of mine that emerge system does not include kernel and security updates for all system files including the logger. If you include GLSA support though that would mean anything gui or web based on the system. but not difficult since the glsa is available.

perhaps emerge uptodate

I'v been using Gentoo as my main OS since the launch of C2D. I tried it before, but since I like to experiment, just used binary distro (Debian-->Ubuntu-->Debian) until I got enough power to recompile the whole system in less then 24 hours.

Somehow in last year, there is a little annoying smell of death. It is at least hard to find any plans. You don't see any posts about Gentoo on any IT site. Packages released long after other distros. IMHO this drives users and developers away. And it certainly does not attract newcomers.
It just seems like headless herd without vision, plans, direction and future.

I'd like to help, but the only use i found was translation (take example of Ubuntu translations) and posting some humble howto or answering in forums.

I trully hope that all said above is ill hallucination. But if it is, than it shared by large number of ex/potential/current users.

Sincerely,

P.S.
Please fix the email validation to accept something like first.last@somthing.com

Congrats for your reelection!

About communication: at least get an automated GWN/GMN out. With stats generated from bugzilla (like in the old GWN), stats from the forums, stats on ebuilds, last rites, some graphs, etc. This way, even if the Newsletter folks are busy elsewhere, we get some info and we see that things are happening in Gentoo land.


About getting things done: it seems there are some decisions to be made. Most Gentoo devs seem to be working on ebuilds. There isn't enough manpower to perfectly maintain and create all packages we'd like, and there never will be. It's been like that for a long time now, and from a user's perspective it seems Gentoo reached status quo on this and nothing is being done to solve the problem. Hence a sense that quality and reactivity are dropping, compared to Fedora (!) for instance.

As a user, I'd really like to see essential Gentoo stuff being worked on. Portage for instance: fixing the -t option, adding the ACCEPT_LICENSES features... stuff that has been broken or missing for like forever. Focus on the toolchain, on @system, on default configs for X or for networking.
But sooner or later, you'll have to trust the community with simple, non-critical application packages. (And no, Sunrise is not the answer we're waiting for - cut this IRC requirement!). It's obvious that devs can't keep up with all ebuild requests in bugzilla; it's probably time to accept it, to stop pretending, and to find a solution.

Good luck :)

Yeah, get things *done* - even if you're just covering 95% of the users. Don't be afraid to break old stuff. Provide users with up-to-date information.

It got better during the last months or so, but still, I think the devs should still be more communicative on the web.

Gentoo needs an User-Evangelist. ;) Someone that writes a column regularly (!) on what's going on in the gentoo-dev-world (yes, the controversial issues are interesting too).

For a lot of users, nothing seems to happen "behind the curtains", but in the end I believe, it's just lack of communication.

I think one of the problems with gentoo is that it has become complicated.

At one time, an ebuild basically pulled the sources and built them.

Then Use flags where added
then ~x86 and the like where added,
then /etc/portage/stuff was added
then layman overlays were added
then sets were added

It's impossible to keep track of this stuff, and also impossible to keep a running system with the newer software on it. kde4 has been a mess and just the other day I unmased the /usr/portage/ kde4.2 whatever it was, and now it won't start, something about a config problem.

I have no problem using bash, or reading a bit to figure things out, but gentoo has just gone way overboard, adding warts to the build system.

Now I'm not saying that the warts aren't necessary or even that they aren't useful. I'm saying they are confusing to track and understand.

So in order for gentoo to fix this problem as perceived by me, it needs a nice package manager that handles all that in the background.

For example, I happen to like kde3.5 for some projects and 4.2 for others. Do I use kdeprefix, somethings I read says no, others say yes but not recommended.
Or how about sets. A new feature that I've used once successfully by following directions in the forum. Where do I find out what set's are available. Does emerge tell me? (Not that I can tell).

When I first started using gentoo, I had a pretty good understanding of how the system worked. Now, I feel that I have to put my blind faith in the developers and often that faith is rewarded, and often that faith is punished. My fear is that the system is too complicated even for developers to handle, and they are often missing the tricks they should be using.

If you want to improve gentoo, I think usablity is key.

Sincerely,
Chris Bruner

It would be nice if the community was a little bit more friendly. That being said, any questions new users pose are normally answered, just often in a backhanded way.

Personally, I think the main issue with getting new users is improving the resources on the net for learning how to use Gentoo. The website has a number of documents on it that are out of date, and the newsletter stops in november of last year.

When I volunteered to try and help out with the above, i was told to learn Guide XML and start looking at the documentation bugs in bugzilla. Now I'm starting to do that, but it still represents a very high barrier to contributing; there are also sections, like the website and newsletter, that need more of a project approach than a bug patching approach.

Conversely, I've been able to add information to the Gentoo wiki with ease, and the information on there isn't covered in labels saying it isn't maintained (whether or not that's the case).

There seems to be a school of thought that suggests new users shouldn't be welcomed into Gentoo till they have enough knowledge to make their way in themselves. I can see the point behind that, but I tend to believe that by enticing as many people as possible into using the distribution you have more potential contributors and a better end product. I'd like to see the council putting someone in charge of lowering the entry barriers into using Gentoo and helping with new users.

I think the problem of discussions are not discussions by themselves but more how people in Gentoo handle it. To be concrete we need to find a way to be more

- to the point
- solution-oriented
- listening, not telling

A few more people acting like mediators maybe could help. If only it wasn't that hard to learn.

I will hopefully publish them on flickr once I'm back home ^^;

That's great. I wish could have been there again :( maybe next year.

Where are the pictures? :)

You can add up autotools + actual autotools code (*.ac *.am *.m4) or just the generated code (Makefile.in configure) and maybe make. You may do the same with cmake as well. If you start thinking about how big something is I'd say right now cmake is about 3-4 slots of autotools...

The fact cmake is built on c++ just makes it having one more dep, nothing more, nothing less.
the fact it's about 5 times the size of the autotools... Again it's just something you may or may not consider, you claim about 500k for the autotools generated files + autotools code + m4 bundles for a simple project, even if a simple project won't need additional m4...

You may love your new shiny toy and you may mock kids using vintage ones or you may just try find where a tool is better and where you can improve the other and try to use the one that works best for you for a specific task.

For wesnoth apparently autotools at least here works better and since autotools is what comes from the rest of the toolchain doesn't add up. Since I do not use cmake it does add up for wesnoth and it takes some more to get the same program. In the end I'd like to have wesnoth built by autotools (even better built by bash + make as that's what autotools gives you) instead of cmake since it works better for me.

Sorry if I answer to a somewhat old post
I absolutely concur with your point of view.
HAL is complicated and not really useful, it's a brain-dead back step.
A good bunch of udev's rules could maybe be used without any difficulty to provide most of hal functions (e.g. mounting); the remaining ones maybe doesn't serve ...

P.S. An example I've noticed is the custom configuration for Xorg's keyboard and mouse with hal: it's such a mess and plain ugly.
xorg.conf's input devices section was indeed simple in comparison to un-explicable xml in
/etc/hal/fdi/policy.

Diego, maybe it's just the way (somewhat offensive maybe?) you presented your point of view, you know - there are some people with "offensive" attitude on gentoo-dev and you imagine how reception looks like.

>> Also having over 500KiB of buildsystem
>> scripts for simple hello world-size project
>> is pretty ridiculous, don't you think?

> dev-util/cmake-2.6.3: 429 files, 25 non-files, 24923.813 KB
> Absolutely.

If it wasn't clear enough - I meant buildsystem files distributed with *project* itself - so you should compare several CMakeLists.txt files with shipped .cmake modules with aclocal.*, Makefile.* and configure* scripts (and libtool files of course as well).
But following your logic, equery list automake shows four different versions slotted, what about this?

I guess your (Diego and Luca) main objections are:
- presence of C++ compiler
- dependency on libstdc++
- not robust bundled cmake modules
- cmake depending on xmlrpc-c can be fixed on Gentoo side if it really hurts you that much
- umbrello depending on kdepimlibs and thus akonadi was not upstream fault but Gentoo devs layness and I fixed it already in case you missed
- RPATH issues - well, those are just bugs that should be fixed - Niemand ist perfekt, right?

So it just leaves us with general C++ rant and insufficient cmake bundled modules (valid point imho).

Sorry but if they are just a "quickstart", it is a *seriously stupid* way to provide support do buildsystem, because then you get 10 projects with at least 8 different modules to do the same bloody thing. Sure there is the same problem with autotools, but it really does not solve anything.

Why, why, why, why. Why X11 team is doing that? Because they haven't followed my advice I gave more than an year ago, maybe even two years ago. Yes, it might sound strange to you but it happens that following the advice of somebody that knows some topic better than you can usually resolve problem. Why does it take weeks to convert mysql? _Because they bloody idiots in MySQL did not write autotools!_ they wrote crap based on autotools, which is the same that KDE did with 3.5 series.

Sorry but autotools are just an old relic as much as the presence of commandline is: it's always said by people who like shiny stuff and just that. Sure I'd love if we were able to replace autotools but cmake is not up on par yet.

By the way: why did KDE 4.2 require akonadi to install umbrello? Wasn't that a buildsystem issue after all?

illogic-al: you should never have messed with the libtool script in the first place; nor with Makefile.in; if you did it means that either you found bugs (which would be the same as messing with cmake original source code), or you were doing something seriously wrong. As for the problem being simply FindRuby, have you checked FindJNI yet?

Oh yeah but cmake just provides a basis, I forgot, all the rest of the world has to reinvent stuff, because the _one big huge issue with autotools_ (the presence of N different variations of m4 files) is left untouched, for the nostalgic I guess.

What autotools seriously have lacked for a long time, and caused a critical mass of crappy buildsystem to spawn, is documentation. CMake seems to have had Kitware to push through by writing the buildsystems or instructing people to in the first place. The fact that KDE is taken as an example is probably the only reason why it can be used.

Point is: KDE 3 had a seriously crappy (and very flawed) build system, and lots of people copied from that instead of using autotools properly. Which is why we got so many broken buildsystems out there. Fixing an issue in a properly-written buildsystem usually take me five minutes; ask Lennart, for whom I fixed a pulseaudio build regression before he took the plane for BOSSA.

Only practical reason to choose CMake over autotools is Windows support. And I can accept that well, what I find stupid is to say that it's _perfect_ and it has not to change. That's simply stupid.

Oh by the way the FindRuby module which is broken I reported basically immediately after I first tried CMake since I wrote a better one than the one shipped at the time (which was simply not working); the report was ignored until a kde.org guy submitted a different version; why? why? why?

Yeah sure, keep on f*cking trying.

Maciej Mrozowski

> Find${PKG}.cmake modules bundled with cmake are mentioned (in Documentation) to be simple and "quickstart", rather > than reliable robust solutions for production - so your argument is quite invalid here, Diego.

Basically you are telling me that you have to redo the equivalent of your .m4 files provided since they are bogus?

> What's the most important in CMake - it's much harder to write bad cmake script rather than bad autotools/automake
> /libtool script.

Seems you autocountered this statement telling you have to rewrite basic checks since they aren't provided by default...

> If autotools are that great, easy and all, then why don't we see yet mysql and openldap split ebuilds in tree?

Because upstream want things differently and you try to address upstream in order to have some agreement before gutting their application randomly mostly. Then, as Diego pointed for mysql, you may have other issues regarding
how things are built that are to be fixed.

> Why does it take weeks to covert libmysqld from static to shared library?

Same reason as before.

> Why X11 team is currently fighting with xcb ABI change consequences caused by broken by design libtool files? (.la)

Because nothing is perfect? Because libtool isn't that necessary anymore and could/should thinned a lot on systems that can do without it IMHO.

> Also having over 500KiB of buildsystem scripts for simple hello world-size project is pretty ridiculous, don't
> you think?

dev-util/cmake-2.6.3: 429 files, 25 non-files, 24923.813 KB

Absolutely.

illogic-al

- libtool is a tool made to hide away gory details certain systems had, pkgconfig nowadays solve most of the problems in a nicer way indeed. Still I wonder why you had to fiddle with .la files...

- I have looked at cmake the first time kde4 started using it and my eye bleeded. the syntax was horrible. I looked it again now and the syntax got at least nicer but still it isn't any better than autoconf + automake.

- For a bare autotools project you have 2 files, Makefile.am and configure.ac I please you to take your time and check the new documentation about autoconf or look at the Diego's articles about it.

Benjamin
1) cmake is easy to deploy.

last time I checked it depends on:
net-misc/curl
dev-libs/expat
dev-libs/libxml2
dev-libs/xmlrpc-c
a C++ compiler

I do not chain back deps, I'll let you do this exercise by yourself

autoconf
>=sys-apps/texinfo-4.3
>=sys-devel/m4-1.4.6
dev-lang/perl

automake
sys-devel/autoconf

libtool
sys-devel/autoconf
sys-devel/automake

implicitly bash and a proper C compiler also.

sooo basically... perl and bash.

now, on windows maybe the deps are different, maybe you just install the executable (as you can do by using cygwin or msys as well)

2) cmake is a lot easier to learn.
Probably is better documented, and more people is giving you better examples for start. Autotools main fault is the fact since few years ago the documentation was quite poor and scattered, add to it the fact nobody is stopping you to abuse bash or make instead of using the features already provided and you see why people perceive autotools (automake in particular) that bad.

3) Why learning several if learning one suits?
I like to have a toolbox, not a single big hammer. You see the tendency to have domain specific languages to solve better different issues. In this case makes little difference taking a some small single domain languages and lump them together probably.

4) cross platform support.
You cannot claim it is better than the autotools one

Looks like it again cmake strong point is windows. Everybody loves windows.

Find${PKG}.cmake modules bundled with cmake are mentioned (in Documentation) to be simple and "quickstart", rather than reliable robust solutions for production - so your argument is quite invalid here, Diego.
What's the most important in CMake - it's much harder to write bad cmake script rather than bad autotools/automake/libtool script.
While packaging KDE4 for Gentoo (it will be two releases now, and live KDE releases in overlay for a couple of months), I've seen enough to state that CMake is in any way better to get things done. If autotools are that great, easy and all, then why don't we see yet mysql and openldap split ebuilds in tree?
Why does it take weeks to covert libmysqld from static to shared library?
Why X11 team is currently fighting with xcb ABI change consequences caused by broken by design libtool files? (.la)
And why KDE Gentoo team can easily split/merge packages in any possible way anytime?
And why we can fix or workaround most buildsystem issues in a few minutes without exchanging unnecessary emails?
Autotools are just an old relic kept for backward compatibility and should die as soon as possible.
Also having over 500KiB of buildsystem scripts for simple hello world-size project is pretty ridiculous, don't you think?

As for cross-compiling, I'd just point you to all the non-ruby modules.

P.S. as this is free software should you have a problem, you could a) fix it, or b) report the problem.
I've seen repeatedly how the cmake folks are very responsive to either.

"Still I don't see how harder is the autotools set compared to cmake IF it is supposed to give you the same results (dependency tracking/resolution a la make, template language a la m4, running commands a la bash)."
Because you haven't looked.

I'm neither programmer nor build tools guru but have had to mess around with Makefiles, Makefile.ams, Makefile.in and my personal _favorite_ the libtool file. It is orders of magnitude easier to beat a CMakeLists.txt file into submission.

You may point out that the cmakelists file doesn't provide all the functionality of the other, to which I'd reply: "So?"

The point is, with cmake, I've never needed to do anything outside of this file. And if it takes care of everything which autotools does, not forcing me to figure out how it works, then good.

If I'm only compelled to learn about autotools features when they break (and I am) then cmake is automatically better by virtue of the fact that I have never found it necessary to learn their analogues when using cmake.

Hi Luca

I couldn't really believe my eyes when you went on to say that if you add the build time of cmake, it's slower than autotools. Oh, and then the 15 seconds of the build time... when I look at my university or the SE jobs I've done in industry, I've gotten to learn a number of things:

1) cmake is easy to deploy. Installing it is a onetime operation for a developer, so who cares. But cmake makes it easy as it has easy to deploy packages readily available. Installing autotools on linux is kinda easy as they're mostly already available, but on windows it's harder. I know, it's a one time operation, but it makes a difference. It is especially easy to deploy because it supports project files for different IDE's. That's really a biiiig plus for many people.

2) cmake is a lot easier to learn. That's a subjective thing I know, but I tried learning autotools but I always failed because of the awquard syntax and the complexity of the system involved. It has several tools and for a beginner it's not easy to see through this. cmake is one language and a pretty simple one at that. It's not without flaws, but my first attempt on cmake succeeded, my first attempt at autotools failed. Biiiig difference.

3) Only one langugate. You say that you already have to know several languages (programming, scripting etc) where is the difference? Well, why learning several if learning one suits? You don't answer that question at all

4) cross platform support. It's not perfect in cmake, but it can be made work quite easily as I've already done. Flameeyes has an example above of a broken build system and concludes from this that cmake cross-compilation is kinda broken? Well, how many broken autotools buildsystems are there? Should I conclude autotools is completely broken? Not.

Yes... cmake is not perfect and has quite a number of flaws. Flameeyes has pointed out a number of them even though I don't agree to all of them.

But concluding that cmake is worse because... well installing it takes more time? This is a no-argument

As for cross-compiling, I'd just quote the FindRuby.cmake module:

FIND_PATH(RUBY_INCLUDE_PATH
NAMES ruby.h
PATHS
${RUBY_ARCH_DIR}
/usr/lib/ruby/1.8/i586-linux-gnu/ )

It makes absolute sense to hardcode that last path, does it? And where is the Ruby cross-compilation support?

If you mean you can override everything to force the thing to fake cross-compile support, GNU make based buildsystems are just as fine.