lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Creating an lmi schroot from scratch


From: Vadim Zeitlin
Subject: Re: [lmi] Creating an lmi schroot from scratch
Date: Mon, 20 Jul 2020 21:33:10 +0200

On Tue, 9 Jun 2020 23:33:48 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

GC> Oh, wait...you want to skip all that, even the chroot creation...then
GC> edit 'lmi_setup_01.sh' and skip as much as you want. Maybe you don't need
GC> any 'lmi_setup_NN' script with a number lower than 30 or even 40, which
GC> means you don't need to run anything as root. If there are some steps in
GC> the 20-29 range that you do need, you can apply those manually. You'll
GC> probably still need these harmless files
GC>   lmi_setup_inc.sh
GC>   tmp/schroot_env
GC> that are created in 'lmi_setup_0*.sh', but those don't require root.

 Hello,

 I've finally tried to do this, but quickly realized that adapting
lmi_setup*.sh scripts to my use case was hopeless, as they're solving a
rather different task from what I need to do. Basically, these scripts
initialize plenty of things from scratch (including many that I don't need
or want at all, e.g. I really, really would hate if the automatic script
touched to my precious hand-crafted Git configuration), while I just want
to be able to install the dependencies and build lmi when I already have
its checkout. I.e. I start from a working system and an existing Git
repository rather than some primordial void, unlike these scripts.

 The two approaches are simply not reconcilable, and I can't even use
install_msw.sh because of this, as it assumes that it needs to run Git
checkout too ("inhibit_git_clone" doesn't help because, first of all, my
checkout is never in /opt/lmi/src/lmi and I don't want to eviscerate
anything anyhow). So I've ended up using completely different and, of
course, much simpler, script for my own builds (which I will show in a
separate message slightly later). It is, of course, a pity, because now I
need another script to maintain, but it seems unavoidable.

 One tiny thing I've noticed while writing and testing them was that
apt-get invocation in lmi_setup_20.sh didn't install "patch". I guess it
must be installed by default on RHEL, as I don't really understand how
could it work otherwise, knowing that patch is used in lmi_setup_21.sh.
It's probably not really necessary to do anything here, but I'd still add
"patch" to the list of installed packages just to be sure it's installed.


GC> And if you devise a way to use these scripts without root privileges,

 This isn't possible as long as we use the directories outside of the
current one and home directory, i.e. /opt/lmi, /etc/opt/lmi, /var/opt/lmi
and /srv/cache_for_lmi. I think it would be worth changing this as using
directories under / is a MSW-ism which is being phased out even on this
platform and is basically unheard of under Unix. The only one which is
somewhat non-trivial is /etc/opt/lmi, which should be made configurable,
instead of hard-coding it in both makefiles and sources.


 To try making this post at least somewhat constructive, I think it would
be nice to factor the post-build part of install_msw.sh out of it, e.g.
maybe have a separate post_install.sh or a "configure_settings" target in
the main makefile, that would create expiry, validated.md5 and passkey files
as well as configurable_settings.xml itself. And if we could make locations
of these files configurable/overridable via environment/make variables, it
would be even more convenient.

 Would it be useful to try to propose patches doing this?

 Thanks,
VZ

Attachment: pgplaIm6Oh6yI.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]