Multilib lunar

Auke Kok sofar at foo-projects.org
Thu Sep 3 05:06:09 CEST 2009


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.

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

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.

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.

Cheers,

Auke


More information about the Lunar-dev mailing list