diff-ing back moonbase module updates into zlocal

[Zbigniew Luszpinski]

Sunday 02 of December 2007 12:35:03 Gb wrote:
> 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

lvu depends hal | grep ^x
(it is not useful as it returns also recursive deps which are not needed 
usually and mess output)

The other method invented by me is to use mc and search for DEPENDS files with 
hal word in moonbase/xorg7 directory which will return for hal only 
xorg-server module.
It is better for solving dependency problems because output is not messed with 
recursive deps. I always use it for fixing depends.

Hint for lvu depends author: nonrecursive command would be very helpful to 
have.

> Or in Guillaume's email here: 
> http://foo-projects.org/pipermail/lunar/2007-December/007868.html

If you use non standard dir you have to remember about consequences:
X apps may break if you manually will not tell them about your X path.

> 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?

moonbase/zlocal is designed for such needs.

> 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 know this is not comfortable for everybody but we have to have some standard 
set of build to avoid mess. There are thousends of build options and 
parameters which when used together may break Lunar in billion ways.
Our tiny community is not able to track every possible combination of options 
in every module (most of them depend optionally or not on other modules which 
make everything even harder to track).
This way we have standard base from which an power user may zlocal to 
individual module (and come back to safe base if something fails).
For most used (and safe) options there are questions during lin to better meet 
user needs.

> 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.

Me too, very often. But the zlocal is designed for this purpose.
This directory for rebelliants is also source of ideas for further development 
of Lunar. Like in democracy if you send the diff(rence) to Lunar ML and it 
will be accepted by majority (or developer) it will appear in official 
moonbase.

Sometimes the great patches or ideas which look great for first time end up in 
trashcan later (e.g. when from Lunar ML you will learn about its weaknesses 
or realize about them yourself). Treat moonbase not as something hostile and 
governed by evil people who want impose their will to other but like safe 
place where you can return when something goes wrong. When I started using 
Lunar I had the same opinion as you. The longer I use Lunar the better I 
understand advantages of it and see I was wrong.

Lunar developers aim is to maintain moonbase in a way which will keep it safe 
for everybody and fresh as possible. The safe word is placed first because 
this is #1 priority thus some modules are still old for _some reason_.

> Using the modules always "as they are given" seems to me exactly the same
> as using binary modules from a binary-only distribution.

If you set up custom CPU optimizations it will be faster. Lunar is also less 
bloated by default (however recent Lunars are fatty).

> What keeps Lunar apart from the crowd is letting people customize their own
> system.

That is why we use it. zlocal rulez.

> 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.

I invented some tip which solves this: just delete the same files in 
zlocal/module and make a symbolic link to moonbase module's file.
For firefox I have symlinked all files except BUILD. So firefox is always 
updated but BUILD in my way.

It is harder to submit because I must clean up all custom changes before 
submitting but still find it comfortable.

> So, I am thinking about a sort of diff-ing back the new foo version
> from the moonbase into my local foo version.

No need. Just read svn logs (or commit ML) and you will know what is going on.
You can always edit lunar update list to not update everything.

> 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.

I think all above tips solves your problem.

> Is there something like that in Lunar already?

Rather not. But my tips are non-conflicting :-)

> Would you like this feature added to Lunar?

No. Except nonrecursive lvu depends command which would be very helpful to 
have.

> It would create a second level of customization / optimization;
> advanced users might appreciate it. Everybody else could ignore it.

I would like to have option to write my own $CFLAGS, CXXFLAGS and LDFLAGS 
instead of lunar optimize. Now I use zlocaled and patched plugins in binutils 
and gcc modules.

zbiggy