This Time Self-Hosted
dark mode light mode Search

Importing someone else’s code

I already maintain, in the tree, an ebuild for the Nimbus GTK+ Engine, that is used by Sun Microsystems on OpenSolaris and Solaris Express. I liek it, it’s quite nice and it was a pleasure to package as it worked almost out of the box (I had to patch a few things but it’s fine now).

Today I looked at the JDS directory where Sun keep the sources of the pieces of code the use on their modified Gnome environment, for the only reason to find something that might be useful to import in Gentoo.

There are a few things I could probably package in my overlay for the sake of it (Sun’s backgrounds and GDM themes — we have RedHat’s and Mandrake’s artwork packages after all), but my attention was caught by an “ospm” package, which seems to provide an interface to the status of printers.

One thing I love of Free Software is that you can make use of software that has been developed by someone else from a different target without problems. Unfortunately this was not the case. While I hoped for something that could be usable under Linux, ospm itself has a few Solaris dependencies too many (that’s why it’s called the OpenSolaris Printing Manager, I suppose).

Anyway, this made me think of a couple more issues. I have said before I’d like some eselect tool that could allow to switch different tools on a Gentoo system without having to write one module each, for instance for tar (so that one could choose between libarchive’s bsdtar and GNU tar), or whois clients.

Debian already has a software called “alternatives” that does that. I wondered before if it’s possible to import that one in Gentoo and make use of that, rather than reinventing the wheel again… but as far as I know it’s tightly related to Debian’s dpkg (just like eselect is unlikely to be ever used outside Gentoo).

More interesting instead is the fact that Cygwin ships with an “alternatives” package, that is not based on the one from Debian, but rather from the one in Fedora (chkconfig package). We already do import a few things from Fedora and RedHat, and I know Donnie did package a few more things from them before. I really should try that out and see if it works. It certainly makes sense not to have to worry about reinventing the wheel once again if somebody did so again, even if it breaks the “Gentoo way” of using eselect (but one could implement an eselect plugin over alternatives of course).

So to keep it short to have time to do some work, I’ll certainly look to see if, rather than having to invent something new, we can reuse something that fellows developers developed and tried already.

Comments 6
  1. “Why reinvent the wheel when other are available?” “I need a round wheel, a square one doesn’t fit my needs”That said if you think alternatives works for the task, why not providing it?lu

  2. Will there be an eselect plugin to select, whether i want to use alternatives or eselect? ;)But seriously – why not eselect plugins for all this stuff you mentioned?

  3. Creating N micro-plugins for eselect is a burden, as you duplicate a huge amount of code with no good reason. My idea was to leave eselect generic, and let the various ebuilds to register themselves. Which is what alternatives tackles down again.

  4. better having eselect switch that:- installs a wrapper when needed.- gives you a list of programs and their alternative implementations installed- let you switch them using something more than a bare symlink (a C/script wrapper?)- automagically switch to something else if you unmerge the used alternative or remove the wrapper otherwise

  5. Hi DiegoNice if you can package sun icons and metacity theme they look awesome.

Leave a Reply

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