[Pkg-ltsp-devel] features i'd like to work on

[Otavio Salvador]

Vagrant Cascadian <vagrant at freegeek.org> writes:

> On Tue, Jul 04, 2006 at 09:16:57AM -0300, Otavio Salvador wrote:
>> Vagrant Cascadian <vagrant at freegeek.org> writes:
>> 
>> > the first one is a wrapper around chroot that does special things like
> ...snip... 
>> I like the idea but I found some problems with current code:
>> 
>>  - arch detection is debian dependent. There's already made code to be
>>    generic in set-arch and you might do a look at it;
>
> yeah, it was just a quick and dirty implementation. if you read the
> TODO comments, you'll notice i was aware of this :P

Ok, good.

>>  - impossibility to set ROOT to something different of /opt/ltsp while
>>    in ltsp-build-client it's possible;
>  
>> The way the I see to workaround this issues is to use a ltsp common
>> plugin repository to set the architecture and root running same code
>> that will be run by ltsp-build-client. 
>
> yeah, i was thinking some of this stuff could be moved into some common
> functions.

I think that we should start to use the plugins for most of functions
as possible. Doing that we can share more code against all parts of
LTSP and increase the code quality.

Currently we have:

 /usr/share/ltsp/plugins/{common,Debian,Ubuntu,...}

I propose:

 /usr/share/ltsp/common/{all,Debian,Ubuntu,...}
 /usr/share/ltsp/ltsp-build-client/{common,Debian,Ubuntu,...}
 /usr/share/ltsp/ltsp-update-kernels/{common,Debian,Ubuntu,...}
 /usr/share/ltsp/ltsp-chroot/{common,Debian,Ubuntu,...}

What do you think about it?

>> The most complicated problem
>> is, when the user use --base it won't be passed to ltsp-chroot and
>> then we'll need to pass the commandline option. That won't make too
>> much difference of current way to do it.
>
> which could be handled by setting the ROOT environment variable, or
> putting a configuration file in /etc, or adding a commandline argument
> to ltsp-chroot (all of this was possible with the lessdisks version).

I don't like to pass environment variables for that use. Configuration
files should be use by us, by default, but let to user change our
settings if need. I think that we should use commandline options for
it allowing we reuse the modules between all possible parts of ltsp.

>> > i'd also like to split some of the functionality found in
>> > ltsp-update-kernels get split into the ltsp-client package, and have it
>> > run chrooted(or in the case of a different architecture, on a privledged
>> > client with write access of some sort). then the ltsp-update-kernels
>> > package would mostly just copy files into place(and maybe run chrooted
>> > scripts if the architecture is supported), rather than the special
>> > network-bootable preparations(mknbi, yaboot, netabootwrap, etc). this
>> > way we could get support for multiple architectures.
>> 
>> I didn't understand this last one. If we remove mknbi and like we
>> loose support to anything but pxe. No?
>
> what i was suggesting was to move that code (mknbi, yaboot,
> netabootwrap, etc) into a script within the chroot that gets run
> chrooted (or on a priveledged client if the arch is incompatible).
>
> so ltsp-update-kernels would do something like this:
>
> * look for chroots with supported architecture
>   * run chrooted script (for mknbi, yaboot, netabootwrap, etc)
> * copy images and/or kernels into the tftp directory
> * other tweaks (such as pxe configuration)

I see.

I agree.

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio at debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
---------------------------------------------
"Microsoft gives you Windows ... Linux gives
 you the whole house."