Re: [Dragora-members] Dragora package management

[Kevin "The Nuclear" Bloom]

Matias Fonzo writes:

>> Asunto: Dragora package management
>> Fecha: 2020-05-12 14:23
>> Remitente: Michael Siegel <address@hidden>
>> Destinatario: Matias Fonzo <address@hidden>
>> I've been looking into the Graft guide again but have decided to put it
>> aside for now and concentrate on getting the website generator done.
>
> That's fine.
>
>> There are two reasons for this: One, there are many issues with that
>> guide and I just don't have the energy at the moment to write them all
>> down and think about how to fix them. 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".
>

It seems to me that using the more "primitive" approach is far simpler
than the Nix/Guix method. Keep in mind that "simple" is NOT the same as
"ease-of-use." I would agree that Graft may be "complex" but it's
solving a rather complicated problem. My question back would be: Is
Graft's "complexity" the result of simplicity or poor design choice? For
example, if someone chooses to use wpa_supplicant for wifi connection
instead of wicd. WPA is far more "complicated" due to the fact you have
to do everything yourself whereas wicd is far "less complicated" due to
the UI provided and automated items. WPA is most likely simpler, whereas
wicd is easier to use yet more complex code-wise.

On the other hand, Emacs vs Moe. Emacs has become very very complex -
this is not only because of endless power within the editor but also
poor design choice. Emac's complexity has to do with people continually
adding and adding and adding stuff to it. The poor design choice is that
people keep adding stuff to mainline Emacs. Make it modular and it
wouldn't be as big of a concern.  Moe, which keep in mind is VERY
different than Emacs, lacks this flaw. It's designer said "I want Moe to
edit text." That's it. The design is straightforward and
simple. Simplistic and good design.

Not sure if any of this makes sense.

>> 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...
>
> I know that writing Qi in /bin/sh has its limitations, but for what it does I
> think it does pretty well.  Tomorrow I'll see about rewriting it in C or Perl,
> for that I lack time for learning.

Going by lines of code isn't always synonymous with complexity, poor
programming, or bloat. Depending on the language, problem, and project
goals any program can have any number of lines. If I wanted Qire to just
fetch packages, it would be like 200 LOC but if I want it to fetch,
install, upgrade, list, display info, build index files for repos, and
do all of this with [possibly] many versions of the same program it's
definitely going to be more code! As Matias mentioned, code-style is
important too. If you create unreadable code, you may save on lines of
code but at what cost?

Just my 2 cents.

Kev