Gentoo vs Arch package base
 

Hello fellows!

Is it true that in Gentoo there are much more programs in repos than in Arch+AUR?

And second little question: how's in Gentoo with systemd at the moment? I read the news that they fight, trying to create udev fork which allows to avoid using systemd and stay with bash scripts or something... How successfull is this fight?

Hello

I'm running Arch at the moment, but the last time I checked, Gentoo had more packages in their repositories. I'm unable to comment on the current state of systemd under Gentoo.

Do you count AUR?

+ 1 more general question: do Gentoo maintainers plan to include CDE in their repos in not so distant future?

Here's some good links on the Gentoo/Arch/systemd issue:

http://sporkbox.us/blog/?r=page/95
http://forums.gentoo.org/viewtopic-t-937778.html
https://bbs.archlinux.org/viewtopic.php?id=153063
http://blog.nirbheek.in/2010/08/systemd-in-gentoo.html
http://solpeth.wordpress.com/2012/12...s-perspective/

You can check the following link for approximate package counts on various Linux distros:

http://en.wikipedia.org/wiki/Compari...d_installation

Since those Arch packages found in the Core, Extra, and Community repos are pre-compiled, I'm not sure counting packages in AUR would be the proper method of comparing Arch package count vs Gentoo package count. Technically speaking, I guess both distros might be about equal if you count all packages that could be built from source if you have a working package build. I don't use many packages from AUR and it's been a few months since I last installed Gentoo, but maybe some Gentoo pros will chime in with some thoughts on the matter.

What about ability to build as is? In AUR there are a lot of packages refusing to build without fixing building scripts. Are there packages like that in Gentoo, so that you have to fix ebuild in order to build it?

It's extremely rare when that happens. I know of only one I have ever had a problem with. It was a broadcom-sta ebuild. It wasn't able to compile against a kernel newer than 3.5 or so. . Even then I was able to get a newer ebuild from an overlay that compiles with newer kernels.

What i do know is that the Gentoo repository is very large and contains virtually everything i need, can't even name anything i installed by hand. Fixing build scripts is something very rare. Happened to me once with VirtualBox modules after a kernel upgrade but was kinda trivial, but otherwise the ebuilds usually work. Using the stable branch + a handful of packages from testing (the usual stuff ala Firefox etc.). I don't miss a thing..

What is OpenRC compared to Arch's initscripts that Arch used to have ≈2 years ago? I mean, is it just a bunch of bash scripts which keep booting process the classical way with all the config files like /etc/inittab, etc...? I read a couple of web-pages on OpenRC but it is not obvious to me after reading. It also has some connection to /sbin/init which must be binary file, so I'm not sure about it.

Arch is much more up to date, but uses systemd(it doesn't things worse than openRC..) Gentoo uses OpenRC, now depending if you're using the gentoo package or you go out and decide to build from source you will see boot time differences. No branding will boot faster, gentoo's package is a bit slow.

I don't like gentoo for many reasons mainly just because there is too many patches that wastes space...

Not really. Gentoo unstable is pretty close to Arch as far as being up to date.

If you are referring to the package manager, then I agree. Portage is very slow, but that's mainly because it is the most complex package manager out there. Portage essentially micromanages every package by checking dependencies, compiler defaults, use flags, masks, unmasks, etc. It can also install binaries. Binaries than you can custom build yourself that you can use for other gentoo systems.

What patches would those be? I don't remember having to bother with patching anything the last time I installed.

Patches will be listed in the ebuild, gentoo devs will patch a package so that it works or fixes a problem. I just prefer 100% upstream.