This Time Self-Hosted
dark mode light mode Search

Why I don’t want too many overlays

So, I’m a daredevil, and I’ll risk to publish my disagreement with Seemant in my blog 😉 Now one point is that I’m not sure who should be to fire me, but we’ll see 😉

Seemant proposed splitting Gentoo in different official and unofficial overlays, so that every package set is in a different tree. Sorry Seemant, but I don’t agree with this proposal.

The first simple reason is that there are too many interdependencies that might migrate over time. For instance there are a lot of packages that were added as dependencies for GNOME that now are used by KDE, too (DBus and HAL for simple instances). Where should they go?

I can agree with a Ruby overlay for Ruby extensions that are not used by any other package int he tree. I would agree for a media overlay with rarely used plugins, or stuff like XMMS that cannot be supported entirely in the tree. But I cannot find a Debian-like approach feasible.

Another reason is that it’s easy to lose the coordination between herds this way: the maintainer of a library might change its behaviour without knowing that another package relies on that, and won’t check it against it because the overlay was not enabled in his configuration, and no data about that was available.

Then there are problems like avahi: it’s a generic package, should probably go to the “core” repository, but it requires qt3 if you build with Qt3 bindings support, that would be somewhere else. Where should it go?

Not to count the possible problems with stubborn maintainers that then will just say “well, the package is not in this overlay, I won’t change it, if you want put your own copy”. We know this is going to happen.

Then there’ the eternal problem of misaligned versions. If people don’t update all the overlays at once, you might end up with ebuilds that does not work with other ebuilds in another overlay. And if eclasses are centralised, the problem is even worse.

I get enough problems with users using unofficial overlays and forgetting about them, submitting bugs about packages with patches that are broken by design. I’d rather not take bugs from users that mess up the order of overlays, or when the same ebuild is in different overlays and with different behaviours.

So, I’m for remaining on a single big repository. —

Personal note now: I’ve finally decided myself on the new mobile provider, and now my personal phone number is provided by 3. As I’m 2KM over the border of the UMTS cell, my new phone tried connection to the 3G network every now and then, with my old provider it almost always failed, with 3 I got it on 25 signal, but it’s too weak to actually be stable here, but at least I can move to the TIM national roaming and have a stable signal here.

Comments 4
  1. You’re obviously not one of my fanboys. I need to go find my clique.

  2. I’m with you. No need to split things up even more. The seeds idea on the other hand is a good concept. I just wish the project had anything in it!I think I’ve sad this before somewhere, but a project without any files is in my eyes not a project. It’s just an idea.

  3. the idea of putting X into a separate overlay seems unreasonable.unless the “X” USE flag would start to mean that portage has to take X overlay into consideration. but it really would be a pain to make it all work together, just as you said.if it would happen to be done, there would have to be additional inter-overlay dependencies as well. (and there are situations where deps can get circular, you know).besides open source software is getting really integrated recently. so it’s very tough to separate things from each other.however it might be actually good, but only to some extent. like keeping separate games overlay, and java overlay. most people just want the JRE from java. and java-config.besides seemant said that gentoo is becoming too debian-like. well splitting portage into smaller repositories would make it even more debian-like, no? 😀

  4. If portage could keep track of from which overlay a package was installed and allow overlays themselves to specify dependent overlays, then it’s plausible to split into – gentoo core overlay as seemant proposed, core packages only – main tree, which depends on gentoo core. It’s almost as same as the main tree now. It consists of complicated dependencies packages. – lots of special-purpose overlays which depend _only_ on main tree, no other overlay. If it has to depend on another overlay, it should go to main tree. These are ruby’s, java’s, perl’s, python’s, theme’s…

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.