Multilib lunar

[Peter de Ridder]

On Thu, Sep 3, 2009 at 5:06 AM, Auke Kok<sofar at foo-projects.org> wrote:
> Peter de Ridder wrote:
>>
>> Hi,
>>
>> A while back I did some research in making lunar into a multilib system.
>> After a few attempts I was able to make a new lunar install by hand
>> into a multilib system.
>> Later I was able to convert a x86_64 system into a multilib system.
>> I wrote a howto for this at
>> http://member.lycos.nl/pcridder/extern/lunar unfortunately this isn't
>> accessible anymore.
>> If someone knows/has a place to host this let me know.
>>
>> To really be able to benefit from a multilib system some things should
>> be added to the moonbase and lunar tools.
>> That gets me to the purpose of this mail.
>> I want to put some more effort into it to get the multilib usable.
>> But I got stuck on the moonbase for now, and I would like some help to
>> get to a solution.
>>
>> The question:
>> How should the multilib modules be integrated into the moonbase?
>>
>> Currently the moonbase uses configurations based on the processor
>> type, which is either a 32-bit or 64-bit processor.
>> For multilib both of these configurations should be combined.
>>
>> Possible solutions:
>>  1) Separate moonbase repository/branch.
>>  2) Separate configuration type (like x86_64) for multilib.
>>  3) Packages with -32 postfix for 32-bit multilib version.
>>  4) Some intelligent lunar scripts to create multilib configuration
>> from 32-bit and 64-bit configurations.
>>
>> Pros and cons:
>>  1) Separate moonbase must be kept up-to-date separately.
>>    But it is not limited in possibilities.
>>  2) Another configuration to maintain.
>>    If multilib is not required for a certain module it can use the
>> 64-bit configuration.
>>  3) How to solve the installed files conflicts between the -32 and the
>> 64-bit module.
>>    Multilib versions are only installed if the multilib version is
>> required.
>>  4) Nearly impossible to create I guess.
>>    Least maintenance.
>>
>> Follow-ups:
>>  1) For this solution the question remains fairly the same.
>>    - Which of the other solutions is used in this moonbase.
>>  2) How is the configuration maintained?
>>    - Is it stored in a .x86_64_multilib file postfix or
>>    - Does a .x86_64 config file check for some special multilib option.
>>  3) How to solve the installed files conflicts between the -32 and the
>> 64-bit module?
>>  4) How would this be possible?
>
> this is all fascinating, but I can't stop thinking about your motives.
>
My motives are that some programs I want to use don't come in a 32-bit
version and more important I like to do it as a hobby project. So for
me it wouldn't be waste time, but spend time.
I know there are other solutions like chroot.

> Q: Why does anyone want a multilib system?
> A: To run applications that are not available on (32|64) bit systems that
> won't run on my (64|32) bit system
>
> Q: What applications are that?
> A: Only binary only proprietary software
>
Grub for example and wine. wine isn't such a strong point, since it
already is a separate environment so a chroot wouldn't change much.

> Q: Why would we make moonbase unworkable for just these modules?
> A: We don't.
>
> At least, this is how I see the issue. The only benefit multilib gives is a
> barely marginal one. Desktop systems should just be 32-bit, since everything
> works and latency is much better (64 bits comes as a cost), and nobody needs
> the memory features anyway (in this decade).
>
> So, most likely your efforts will be wasted since there is little support
> from other lunar devs to make all this work. It's been proposed before in
> other forms, but it pretty much comes down to the same conclusion: it's just
> not worth most developer's time.
>
I can understand other developers don't want to spend time on this,
since in there opinion it is useless. I like to work on it for a bit,
but need some help figuring thing. But if none wants/can help me, that
is ok, just to bad for me ;).

> if you could make it work without impacting any module in moonbase (e.g.
> lunar's BUILD code would be smart enough) then I'd be much more interested
> in it... for now I think it's a pipe dream.
>
This is the reason for this mail, to find some way how the moonbase
would still be maintainable.

Regards,
Peter