What needs to be improved in Gentoo?

Kanniball · Posted: Wed Aug 23, 2006 11:12 am Post subject:

+ portage needs *BIG* speedup.
--- now portage is still slow, maybe some improvements can be done like eix does, with a better "cache".

+ support for multiple overlays
--- imagine you have 2 or 3 overlays, it would be nice if emerge --sync could update all of them

+ aggregate all dev's and userlays
--- create one overlay where users and dev's can upload their ebuilds. this will help to get new apps on portage in a faster and better way

+ better etc-update
--- this is one of the weakest points in gentoo IMHO, I have those msg's complaining about new confs...

Cinquero · Apprentice Joined: 24 Jun 2004 Posts: 249

I still don't feel too good about the "each app can access all my files" situation. I think we should really solve that. Maybe by replacing the old user-group-world permission scheme by a user-app-group-world scheme? By default, the app-part would be undefined and ineffective, therefore resembling the old scheme.

In a second step, one could combine that with SELinux policies: if the user executes a binary with the app-part defined, SELinux could automatically switch the app's domain. That way, we could possibly somehow replace the labeling mess in SELinux.

----

Another thing: I recently tried to write a little script that re-emerges all packages which have been emerged using different CFLAGS/CXXFLAGS/CHOST vars than the current ones as defined in make.conf. Unfortunately, that is not possibly because the files in /var/db/pkg do not exactly reflect these variables as defined by make.conf, but as they were set (modified) during the build/setup process. Maybe it would be a good idea to also store compresse make.conf files in /var/db/pkg.

----

Yet another proposal: add a "always/never overwrite" option to etc-update: usually, it is always the same files that one does not want to be overwritten... (store these files' names in /etc/etc-update/always||never) Wildcards support in these files would be great, too: for example to ignore updates to /etc/conf.d.

It seems like there are two groups here: those who want/need to edit config files and those who don't. I still think we should have an automatic configuration mechanism for simple setups at least for the latter group of users: the user should define a package-independent configuration/setup for his machine and the ebuilds should then transform that information into good, reliable and secure config setups. Ebuilds do in some way express knowledge. So I think we should also put the knowledge of correctly (and securely) configuring services there. A simple setup could be, in the first place, a simple client with one NIC, ac97 sound controller, nvidia graphics etc. One could then go on and support more hardware. The extension to other ALSA devices, for example, should be pretty straight-forward: just compare the lspci PCI IDs with the compatibility information stored in the ALSA modules. One could also require DDC functionality to properly detect and optimally setup the monitor. We certainly don't want to support every setup at first.

Paapaa · l33t Joined: 14 Aug 2005 Posts: 955 Location: Finland

mark_alec · Posted: Wed Aug 23, 2006 1:33 pm Post subject:

filterpunk · n00b Joined: 18 Jun 2006 Posts: 71 Location: Portland, OR

beandog · Posted: Wed Aug 23, 2006 2:39 pm Post subject:

cnistra · Posted: Wed Aug 23, 2006 2:41 pm Post subject:

Genone · Posted: Wed Aug 23, 2006 5:02 pm Post subject:

Icer · Guru Joined: 26 Aug 2003 Posts: 395 Location: @home

Dunno if this has been suggested before but here goes. In the packages.gentoo.org the list of packages on the left side of the page could use a colorcoding or symbol markings to show if the package went stable or if it's in testing etc. Though one would propably need to add the arch keyword too so people know which arch was affected.
_________________
Everything can be done. There's just a longer delivery time for impossible projects.

beandog · Posted: Thu Aug 24, 2006 10:30 pm Post subject:

thyrihad · n00b Joined: 17 Jun 2003 Posts: 45

Gooserider · Posted: Sun Aug 27, 2006 2:24 am Post subject: What about a "translation manual"

Another thing that I've run into on occasion is that most of the Paper manuals and guides out there are written for distro's other than Gentoo. Probably RH / Fedora and Debian are the two most common...

The trouble is, many of the books offer useful advice, but the commands they suggest don't work because it seems each distro does it slightly differently.

For instance, I was just trying to get printing working and needed to restart the CUPS servers on my Gentoo box and on my Ubuntu box. I was working in part out of O'Reilly pubs "Linux Cookbook" .
They told me that on a Debian box, I should use "/etc/init.d/cupsys [start | stop | restart]" (this worked on my Ubuntu box) ; and on an RH / Fedora box, I should use "/sbin/service/cups [start | stop | restart]".

This was fine, now what do I do on my Gentoo box? First off, neither example worked as given.

So start digging... After much poking around, I finally find that the command I'm after is ""/etc/init.d/cupsys [start | stop | restart]"

While it would be nice to get publishers to include Gentoo commands in their books, I don't know how easy this would be. Also I have no desire to toss out otherwise useful books I already own.

What would be nice, but I don't know if it exists anywhere, is a "translation table" that would provide a general description of the task, and the commands for Gentoo and other major distros so that if you are familiar with how one distro works you can translate it's commands to Gentoo. (or vice versa, but as Gentoo advocates we don't need to go there... :lol:

)

It may already exist, but I haven't found it yet.

Gooserider
_________________
Box 1: P2 Celeron 400, 320mb RAM, 80GB HD, Cirrus Logic 4614/22/24 sound card, ATI 3D RAGE PRO AGP 1X/2X (sound & video onboard)
Box 2: AMD Athlon 2500+ 512mb RAM, 80GB HD, Gigabyte K7 Triton (Nvidia) mobo, GeForce2 video

yabbadabbadont · Posted: Sun Aug 27, 2006 2:31 am Post subject:

Gooserider: It's good that you are reading up on things, but perhaps you should start with the Gentoo documentation first when working on Gentoo. http://www.gentoo.org/doc/en/printing-howto.xml#cups

Unforutunately, just about every distro out there handles the files under /etc differently. (especially /etc/init* and /etc/rc*) If they would all just agree to do it the Gentoo way, then the world would be a better place.

_________________

Dralnu · Veteran Joined: 24 May 2006 Posts: 1919

Books are biased distro-wise. Problem alot of people seem to have is they don't know the which command, nor locate

The Linux Cookbook from No Starch Press (copyrighted and trademarked, I'm sure) seems fairly neutral. Alot of the O'riely books (the Linux Pocket Refrence actually states this on the cover) are biased due to the writters.

Actually, someone should make a list of the handy books/refrences and list out what they are used for...

/me goes off to make a new thread
_________________
The day Microsoft makes a product that doesn't suck, is the day they make a vacuum cleaner.

Cinquero · Apprentice Joined: 24 Jun 2004 Posts: 249

Example: there is this known-to-be-buggy alsa-lib-1.0.11 ebuild. alsa-lib-1.0.11-r1 contains a bug fix for that. The first one is marked stable, the second one unstable. Why is that? We know that -r1 contains a fixed critical bug, why not setting it immediately to stable? Why not setting alsa-lib-1.0.11 to unstable even when we know of the bug?

This is an inconsistency that just should not be.

yabbadabbadont · Posted: Sun Aug 27, 2006 3:44 am Post subject: Re: Portage bugfix responsiveness

Dralnu · Veteran Joined: 24 May 2006 Posts: 1919

If you have an good refrences, post it here
_________________
The day Microsoft makes a product that doesn't suck, is the day they make a vacuum cleaner.

Gooserider · Posted: Sun Aug 27, 2006 2:40 pm Post subject:

yabbadabbadont · Posted: Sun Aug 27, 2006 7:29 pm Post subject:

Gooserider: Just to clarify, I did not intend that as criticism (if you took it that way), but just as a helpful suggestion for a source of information that you may not have seen.
_________________

Cinquero · Apprentice Joined: 24 Jun 2004 Posts: 249

QA. kdesktop_lock is broken because of an incompatibility between gcc-3.4.6 and qt-3.3.6 (https://bugs.gentoo.org/show_bug.cgi?id=133301). Fortunately, that won't fix because the 3.x gcc series is closed now. And gcc 4+ is unstable in Gentoo.

Dralnu · Veteran Joined: 24 May 2006 Posts: 1919

Cinquero · Apprentice Joined: 24 Jun 2004 Posts: 249

It is an example. Not being able to lock a KDE desktop using stable packages is something one should think about.

Just my .02$ ...

BTW: there is already a bug report *g*

Dralnu · Veteran Joined: 24 May 2006 Posts: 1919

Ever try xlock?
_________________
The day Microsoft makes a product that doesn't suck, is the day they make a vacuum cleaner.

mauricev · Apprentice Joined: 22 Mar 2004 Posts: 197

An emerge toolchain command to produce the functionality provided by the scripts discussed here:
https://forums.gentoo.org/viewtopic-t-282474-highlight-.html

sloppy