Re: various packaging issues

[Dave Love]

address@hidden (Ludovic Courtès) writes:

> Hello Dave,
>
> Glad to see another Guix user in HPC!

Not exactly, I'm afraid.  This is largely academic research as I have to
deal with and contribute to a typical mess of "module" stuff (which
isn't at all modular, or course).

[I'm surprised that something with HPC interest doesn't have
Openfabrics support, which is what I was looking at.]

> Dave Love <address@hidden> skribis:
>
>> * I should specify a disjunction of licences like "BSD or GPLv2" rather
>>   than the conjunction, which seems to be represented as a list (though
>>   the doc doesn't say what a list represents).  I.e. in Fedora-ish
>>   rpm-speak, I have A or B, rather than C and D.  Is that possible?
>
> We cannot specify it currently, so what we do is just provide a list of
> license objects as the ‘license’ field and explain the meaning of the
> list in a comment.
>
> Clearly this can be improved, though we have to pay attention of
> overengineering in this domain.

It seems to me that you need to be able to treat licences similarly to
Fedora and Debian.  They're not obviously over-engineered, and the
treatment of licensing must be constrained by legalities, which may or
may not allow simple engineering :-/.

>> * RPM specs commonly have multiple sources specified, e.g. source and
>>   doc or example tarballs, or configuration files of some kind which
>>   aren't patches.  Is there a way to do that?
>
> The ‘source’ field can be only one thing.  However, you can always
> specify additional origin objects as inputs.  There are multiple
> examples of that.

Oh, thanks, but I still don't see how to use it.  I'd be grateful if
someone can point me to examples; I couldn't find any when looking for
packages I thought might have them.

>> * What if I effectively have multiple build systems?  For instance a
>>   python interface needs to be built with an explicit
>>   "python... setup.py" with an overall autotools build.  While I figured
>>   out how to build and install in that situation, at least for one
>>   python, it looks messy.  I wonder what the recommended way is,
>>   particularly to provide python2 and python3 modules, or for other
>>   things like Java or Perl components.
>
> Most of the time there’s one build system that drives the others, so
> you’d just specify that one.

Part of the issue is how to specify the dependencies^Winputs that a
build system would comprise.  I.e. in Fedora-land, you buildrequire
things like python-devel so that you have what's necessary, which might
change.

> If you really need bits of one build system and bits of another, you
> still have to choose the “main” one, and then you can manually pick
> build phases from the other build system(s) you’re interested in.  I
> think there are a few examples of that, like things that combine
> ‘glib-or-gtk-build-system’ with ‘python-build-system’.  That’s not a
> great answer, but that’s what we have so far.

OK, I'll look.  I did make it work by checking which version of python
was available, but it wasn't neat.

> For Python 2 vs. 3, there’s the ‘package-with-python2’ procedure, which
> you can see in (gnu packages python).

Yes, but that seems to deal with packages just for python modules,
rather than modules which are just a component of something bigger,
which would go in python2/python3 sub-packages in Fedora.  I guess there
are examples, but again I couldn't find one.

For what it's worth, packaging seems to be rather harder than suggested
by the propaganda, and looks as if it's often going to need Scheming
with the Guix framework, which is a bit of a barrier.  I realize I'm
very rusty, and never knew Guile.  (Just an observation from someone
leaping in, without meaning to be critical.)

> HTH!

At least a bit, thanks.  I'll look again and maybe send doc fragments.