Re: [Dragora-members] Dragora package management

[Michael Siegel]

Am 13.05.20 um 03:15 schrieb Matias Fonzo:

>> Two, Graft seems very complicated to me.
>>
>> The second reason has me worry a bit. I've talked to an old Unix guy I
>> know from Devuan (though he's not a Devuan developer) about Graft and he
>> thought the same: Graft seems to be extremely complex. None of us has
>> read the code, though. (I don't even know Perl.)
> 
> If you mean complicated from the point of view of addressing this
> particular program, yes, it may be complicated or even frustrating. 
> That's what happened to me years ago when I looked to the graft for
> first time.
> 
> I think that to understand this kind of program as Graft or as GNU Stow,
> you have to address the concept or concepts behind it.  These concepts
> belong to the 1990s (not that old is bad) but rather to have a package
> structure using the same file system as a database - instead of an
> internal database or files containing an installation log, this has its
> advantages.
> 
> Once this is understood, using Graft is quite simple:
> 
> graft -i <directory> to link a "package" directory under the target
> directory.
> graft -d <directory> to unlink a "package" directory from the target
> directory.
> ...
> 
> It's a form of organization.  Distributions like Dragora (version 3),
> Nix or GNU Guix uses these concepts.  Of course in Dragora it's more
> bare or "primitive".

I see, and I have nothing against that.

>> Now, when I look at the current package management situation in Dragora,
>> I see there's a supposedly very complex Perl script (ca. 1700 SLOC) as
>> the backend to a POSIX sh script (ca. 1000 SLOC). And on top of that,
>> there will be qire, written in Fennel (ca. 800 SLOC) and compiled to Lua.
>>
>> I'm beginning to think that this might not be a solid approach. I mean,
>> sure, package management is quite a complex task. But I have a feeling
>> that the way it is being implemented in Dragora currently (again, not
>> judging the code, only the concept) results in something that is more
>> complex than the solution to the actual problem would require.
>>
>> What do you think?
>>
> 
> As you say, package management is a complex task.  For that reason I
> have tried to keep Qi as "small as possible" in the sense of achieving
> an instruction that can do the basics, which is: install, remove, or
> upgrade software packages.  In addition to build packages through
> recipes.  I see Qi as a package manager that does the basics plus some
> additions.
> 
> Considering that it has 1000 lines of source code for everything I think
> is okay.  Out of those 1000 lines only a portion or some portions of
> that code is used at run-time (when a mode is invoked); you also have to
> take into account the style of the code - for example, writing like this:
> 
>     test "$var" = value && do this ...
> 
> is not the same as:
> 
>     if test "$var" = value
>     then
>         do this ...
>     fi
> 
> which is more formal and clear.
> 
> Both aspects apply to both Qi and Graft, which try to have line breaks,
> new lines, formal code (this adds up to the SLOC count) and good
> comments (if possible). In the case of Graft, it could be "smaller"
> since it offers compatibility with GNU Stow.
> 
> Learning and using Qi can prevent you from learning Graft itself.  But
> learning Graft gives you a finer grain for handling packages and it
> helps you to understand Qi better.
> 
> I don't think the amount of lines of code is alarming in Qi (currently),
> nor in Graft, because for link management it is complicated, and I
> consider that only Perl is quite suitable for this task.  To compare a
> little we can look in the Alpine Linux abuild script[1], this is the
> "light" version of makepkg (from ArchLinux):
> 
> [1] https://git.alpinelinux.org/abuild/tree/abuild.in
> 
> It has a total of 2733 lines (including code, new lines, comments,
> etc.).  I haven't looked, but I don't want to imagine the current lines
> from the original makepkg at ArchLinux.  And this is "only" to proceed
> with the instructions from a build script or recipe...

You are right, the SLOC count in itself is often not much an indicator
of anything. I've just counted the lines of C code in Void Linux' XBPS
package manager (https://github.com/void-linux/xbps/):

~/Downloads/xbps$ find . -type f -name '*.c' -exec sed -e '/^ *#/ d' -e
'/^ *$/ d' '{}' + | wc -l
34844

Well…

However, having three different “layers” of package management
implemented in three (actually four) different languages, is still a bit
weird. Then again, it's probably not that much of a problem. I can't
really say.

> I know that writing Qi in /bin/sh has its limitations, but for what it
> does I think it does pretty well.

The good thing about it is also that I understand POSIX shell to a
considerable degree, which means I can actually study the code. But
then, this is not more than a “works for me” argument.

> Tomorrow I'll see about rewriting it
> in C or Perl, for that I lack time for learning.

I don't really understand what you mean by that, sorry.

Anyway, I'll finish going through the Graft guide as soon as I can and
make a list of things that I feel are overly complex. Then we'll have a
much better basis for discussion.

I'm still interested in helping to revise the Qi interface in a way that
would offer a clear distinction between commands and options. But I
wouldn't feel too comfortable making suggestions for that before I have
a better understanding of Graft (and Qi).


Best
Michael