Archive for category: Gentoo

Why overlays are a good thing

Why overlays are a good thing

1 Kudos

Few days ago I read a blog post regarding overlays written by Diego Elio Pettenò, an IRC fella and, despite I usually agree with him, this time I think he’s damn wrong.

I think overlays are a real good opportunity where to learn how to write (almost) proper ebuild and to learn how versioning, bumping and maintaining packages should be accomplished. Proxy-maintain is option, indeed, but not in the immediate time for sure.

Before asking a developer for proxy-maintaining something, you should be able to write good ebuilds that won’t break things up. A developer is not a mentor and he’s not supposed to be your personal guide.

Diego says that the main reason he dislikes overlays is the fact that, being proxy-maintainer, an huge amount of people will get your ebuild in a timely matter and, the developer, can fix your ebuild before reaching the tree.
I don’t think so. The “timely matter” opinion is barely sharable since the fact that a package is not in the tree means that very few people have interest in it. This means that time doesn’t matter at all.

The second part where a “developer can intercept mistakes before committing them to the tree” isn’t correct if compared to what do happen in certain overlays (at least).
Sunrise, which is my favorite overlay (where I commited tons of ebuilds myself), has a very good system to minimize the amount of poor ebuilds in the overlay: there are three-four developers that took the commitment of being there for replying questions and check & fix novices’ ebuilds. Furthermore, in the IRC-chan, there are five-six dozens of users willing to collaborate and that can help you in writing good ebuilds.
Before committing an ebuild you have to provide a good version of it and wait for a gentoo developer green light. Once you had it, you can commit it in the “non-reviewed” branch.
After few days (a week at most), a developer will read all the ebuilds that have been added in the “non-reviewed” branch, re-review those and, finally, they are pushed in the “reviewed” branch, that’s the public one.
It’s a pretty good system to me.

The main reason I like overlays is the level of engagement. You can write few ebuilds and other people will carry on with those. There’s no single-maintainer but everyone maintains everyone’s ebuilds so you can live your life without being reviled.

I don’t think every overlay is good and I agree with Diego when he says that, usually, overlays “mix should-be-working packages with don’t-even-try” and that’s bad, indeed.
But, for what concerns my humble opinion, I still prefer the approach where I don’t have to bother people asking for a role that I might not fulfill.

August 24, 2010 0 comments Read More
Gentoo Tips & Tricks

Gentoo Tips & Tricks

5 Kudos

Here’s a list of tips and tricks that I learned / discovered during these years.

eix is a very simple, clean and powerful tool that allows you to perform several tasks with absolute simplicity.

  • eix : it will search inside your package names. Can be parametrized in order to search in description, use regexp and so on. It’s faster than emerge and I largely prefer eix to emerge -s.
  • eix-sync : Instead of using emerge —sync you can use eix-sync to synchronize portage tree and then have a brief about what changed between your previous local portage snapshot and the just fetched one. Handful.
  • eix-test-obsolete: This tool is really unknown to many people. It’s very useful when you use mixed stable and testing packages on your system. Simply it checks your package.{keywords, use, mask, unmask} files/directories in order to tell you if you have something you don’t need written in there. Maybe you unmask a package, then you remove it and in package.keywords/unmask you leave an useless trace. eix-test-obsolete will tell you that.
  • eix-remote: Issued with the parameter update is one of the most useful tool I’ve ever had the pleasure to see. A little prologue before. As you might know, there are a lot of “other portage tree” (or rather, overlays) that contains tons of other ebuilds that don’t fit into portage official tree. One of the most annoying thing could happen to you, is when you want to search if another ebuild has been already written or you’re force to write one yourself. The eix-remote update command will be your very best friend. It fetches a “snapshot” of the indexes of almost all the overlays in the world, and allows you to search for an ebuild just issuing eix . In order to get rid of the “remote” database, just run eix-update and your portage cache will be restored.

You should know that /etc/portage/package.{keywords,unmask,use} can be files or directories. It’s very useful having those as directories if you largely use mixed stable/testing packages.

It’s a clean, non-perfect tool that helps you unmasking packages dependancies. How many times did you echoed a package name inside package.keywords file discovering that the package needed a dep that needed an unmasked dep that needed an unmask dep .. and so on? This tools will simplify your lives because it will add automagically the required dependancies to package.keywords. It’s really nice since it auto-recognize whether you have package.* stuff as files and directories. For instance, if your package.keywords is a directory, it will create a file named ‘autounmask-package’ containing all the required unmasked dependancies.

dev-util/lafilefixer is a tool that performs a scan on your system trying to fix up broken .la files. It somehow useful when you have redundant errors regarding those files.

app-portage/gentoolkit contains a lot of useful tools (like eclean, equery, euse) and, of course, revdep-rebuild. It’s a great tool that saved my own ass so many times. Sometimes packages breaks. Is in their nature! So, how can I fix those packages? revdep-rebuild is the one you were looking for. It will check for every dependancies (straight and reversed) discovering if some package isn’t in good health. If that happens, it will automagically re-emerge it.

February 3, 2010 0 comments Read More