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

Re: Restructuring questions



On 03/12/2014 19:57, Daniel Baumann wrote:
> On 12/03/14 19:23, jnqnfe wrote:
>> restructuring work I'm doing on the live-build codebase
> i'm not sure that makes sense.
>
> for jessie, all we can do is small bug fixing, not reworking the code.
>
> for jessie+1 aka strech, we'll move to python anyway.
I hear you, and I realise that Jessie is in freeze status right now, but
I wasn't concerned with trying to make it into Jessie when I started, I
was simply trying to contribute some improvements that would at some
point in the near future might perhaps make it into Sid, if you liked
them. Actually this whole thing started because I was going to (and
still plan to) try to tackle bugs 718225 (not all files downloaded
securely) and 731709 (support uefi), and then build myself a live disk
to use. Before tackling them I wanted to get familiar with the code base
I was to work with, and started noticing things I could try to improve
and started tinkering.

I actually only just found your roadmap page on the website yesterday
and noticed the mention of python. I wasn't aware of this when I started
this work. I'm pleased to hear that, I think it would be a good move, no
more functions and config being loaded by each and every subscript.

I haven't spent too much time trying to improve things, and I won't
spend much more before working on those two bugs, but perhaps if you
like the changes they could be offered on a public git branch; they may
make it into a new version before you've gotten round to transitioning
to python, and perhaps the modified code might even help ease the
transition, or help others contribute other improvements if my
improvements along the way help make the code easier to follow.

Has work actually begun on a python rewrite already, or is it just on
the agenda?

>> 1) What exactly is the use case for a user running live-build with a
>> copy of the utility's code within their build directory?
> to be able to ship a self-contained configuration that requires
> debootstrap and a posix shell on the build-system only.
>
> for the python rewrite, we'll be dropping this eventually.
>
>> 2) The point of the local/bin directory of your build directory is what?
> some people did add once their own lb_* commands, for reasons of being
> able to ship a self-contained configuration, this is the most convenient
> way to do it.
Okay, I'll bare that in mind, but I'll leave those things be. I'll
finish up some other bits and pieces I want to try and address, get it
uploaded soon and focus on tackling those two bugs.

>> 3) File locations. Why is /usr/lib/live/build.sh located there and not
>> in the build directory
> because /usr/bin/lb would not work properly anymore then (without ugly
> hacks).
>
>> why are these here under share instead of lib?
> share is data, lib is code.
Well I have actually tidied up the lb script and initialization code in
my restructuring, which now allows the build scripts to be structured in
a directory, and I thinks its a fairly nice and clean implementation.

Right, but all of the function scripts in particular are code, thus
should exist in lib. So surely something like
/usr/lib/live/build/scripts and /usr/lib/live/build/functions would make
more sense...

It doesn't matter though, I'll leave that as it is and leave it to be
addressed as necessary in the python rewrite.

Thanks for the response. :)


Reply to: