diff-ing back moonbase module updates into zlocal

Gb majinai at warpmail.net
Sun Dec 2 12:35:03 CET 2007


Dear Lunar maintainers,

I use Lunar because I like to re-compile software on my computer
to optimize and customize it.

Lunar makes it possible to quickly fix installation errors, because bash scripts are used.
Indeed, you have helped me many times with compilation / reconfiguration issues,
and I have now learned how to make those changes to the module scripts by myself.

Recently, I have started to see some limitations in the lunar approach.
For example, in my bug report here: http://bugs.lunar-linux.org/view.php?id=310
Or in Guillaume's email here:
http://foo-projects.org/pipermail/lunar/2007-December/007868.html

Lunar is great when it comes to giving users the freedom of creating
new modules or updating existing ones.
But what happens when my idea of a module "update"
clashes with the one chosen by the Lunar mainstream community?

Module dependencies, compilation parameters, source versions, etc. are often subjective.
I understand that maintainers do their best to ensure
that the distribution "just works" for most people.
I can see that a consistent choice is necessary to make sure that all modules
down along a certain "lineage" will compile.
But I may still disagree with some choices.

Using the modules always "as they are given" seems to me exactly the same
as using binary modules from a binary-only distribution.
What keeps Lunar apart from the crowd is letting people customize their own system.

I like very much the idea of zlocal, but I wonder if it could be extended a bit more.

For instance, when I submit a module update, a diff is sent to the Lunar maintainers.
The diff is then merged into the moonbase or rejected.

My idea is: suppose that module "foo" is installed on my system.
I decide to edit it to suit my own tastes; foo is then in my zlocal directory.
The customized foo now works very well with my hardware and I am happier.
Then, somebody updates foo on the moonbase.
I could keep my local version "on hold", of course.
But, I might like the moonbase version too, especially if it's new / has bug fixes, etc.

So, I am thinking about a sort of diff-ing back the new foo version
from the moonbase into my local foo version.
I would then manually check the differences, and obtain my personal new version,
without breaking the "official" version on the moonbase and at the same time saving my valuable
system-specific parameters / compilation options, etc.

Is there something like that in Lunar already?
Would you like this feature added to Lunar?
It would create a second level of customization / optimization;
advanced users might appreciate it. Everybody else could ignore it.
I am looking forward to your comments.

Gb


More information about the Lunar mailing list