Re: [Dragora-members] Dragora package management

[Matias Fonzo]

El 2020-05-13 13:33, Michael Siegel escribió:
> 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.

I know.  :-)

> > > 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…

It does the local and remote part, surely...

> 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.

Different tools or languages for the purpose, and different layers for 
the user need.

As I mentioned before, if you want a finer handling of the installed 
packages, that's Graft.  If you want to handle binary packages or build 
some recipe locally, that's Qi.  If you want to go to the remote part, 
that's Qire.

I know that having different layers can complicate learning for someone, 
but having everything in one can also be very complicated.  By having 
these 3 different tools, we are respecting and following the Unix 
principle of "Do one thing and do it well".

> > 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.

I mean, in the future.

> 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.

Yeah, no problem.

> 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).

Thanks.  I finished the code for the new interface and I am going to 
update the documentation, then I will try to publish a new release 
candidate for testing.  I will let you know by this mean.