[Pkg-electronics-devel] gnucap package.

[Felix Salfelder]

Hello Carsten.

On Sat, Mar 17, 2018 at 10:00:54PM +0100, Carsten Schoenert wrote:
> You need to figure out what the various parts of gnucap do or suppose to
> do. I don't know this peace of software enough to give here a good
> advice. Also the source isn't using any classical portable build
> configuration management like Autotools, CMake or similar. That requires
> a good understanding what the source is made for and how to use the
> binaries and/or libraries. All things I don't have.

gnucap is portable by design, and it does not depend on other packages.
so there is nothing to configure, with the one exception: non-posix
platforms. that's why autotools is considered overkill.

it's not like that, if you are used to autotools, obviously.  i do have
an autotools build system for gnucap [1]. i considered to use it in a
future package, but it does not help, really. particular not in the
discussion below.

> To get more clearness what to do it's a good idea (like always in such
> cases) to have a look at the current policy.
> 
> https://www.debian.org/doc/debian-policy/#development-files
> 
> > If there are development files associated with a shared library, the
> > source package needs to generate a binary development package named
> > libraryname-dev, or if you need to support multiple development
> > versions at a time, librarynameapiversion-dev. Installing the
> > development package must result in installation of all the
> > development files necessary for compiling programs against that
> > shared library.

singular has a libsingular-dev package and (all but config) headers in
libsingular4-dev-common. libsingular-dev depends on
libsingular4-dev-common.

(i think singular does something very similar)

> Mostly this is a bit overkill for no real gain, you have more packages
> you need to understand.

i see your "overkill" point. will try to use fewer packages, see below.

> Mostly the package maintainers just create a
> package 'mypackage-libs' and 'mypackage-dev' to keep the complexity also
> for the users low.

i'm afraid gnucap-dev alone will not cut it. assume somebody runs a
program linked to libgnucap0 and one linked to libgnucap1, then only one
of them could possibly work right. that's against the idea of adding the
version there in the first place.

> >From the packaging side it's always simpler to split a source package
> into more binary packages, but it costs mostly more energy and thoughts
> to reduce binary packages of a source package. So I would suggest to
> keep the package count low as possible.

i agree.

> Rereading my previous answer and looking at the source again I would
> drop the package gnucap-dev and move the content into the package
> libgnucap-dev.

gnucap-dev currently ships the model compiler (binary). maybe i should
undo that, but see below.

> > currently, the jit compiler comes as an extension package, but some of
> > it might move to gnucap-dev, once it's stable.
> 
> Don't try to solve now problems you don't have yet. Just think about it
> once this JIT compiler is ready.

that is a misunderstanding. the JIT compiler *is* ready, but currently
it is a seperate source package. at the current stage it necessarily
increases the package count, while after the merge it could be part of
gnucap-dev (given that it exists by then).

> > in fact, libgnucap-dev was missing the dependency on gnucap-dev. thanks
> > for spotting this.
> 
> No, that's not useful in my eyes. Technically this is possible but I
> haven't seen any package in the archive that is doing this. If I see a
> package libgnucap-dev I assume it also contains the needed header files.

singular.

> Why? What is the winning? It's no oversimplification, dev packages are
> made for this. Take again please a look at the policy.

the policy says

"If there are development files associated with a shared library.."

the development files are not (only) associated to a shared library.

> Users also wouldn't install some header files simply because they don't
> need them for their use case. So where is the difference?

gnucap will not work without the header files. it will not be able to
load plugins, and all (read: most) functionality is in plugins.

that's like python without "import". except python interprets files on
its own.

> I don't think so. Your are talking about shared object code that isn't
> created for the library folder /user/lib or /usr/lib/$MULTIARCH.
> Such code is normally placed within a private folder e.g.
> /usr/lib/$MULTIARCH/gnucap or /usr/lib/gnucap or if platform independent
> in /usr/share/gnucap/foo. That's an important difference to public
> shared libraries.

yes. that is where gnucap-default-plugins (and future plugins) will
install objects to. /usr/lib/$MULTIARCH/gnucap0 will be more useful, but
see below.

> I don't see why this would need header files. And if so you would need
> to add a dependcy on the dev package or place them in a dedicated folder
> under /usr/share/gnucap/.

loading the binary plugins will not need header files. loading the
*source* version will. the source version could be in $HOME/my_project/
.. a modified version of an upstream plugin, or anything really.

> Package gnucap-default-plugins0 is doing this exactly this way and this
> is fine. But you should drop this '0' at the end. You wont have plugins
> with different API versions at the same time I guess.

i disagree, as i have no control over that. if somebody links to
libgnucap0 and uses the plugins, (s)he would have to recompile or link
his/her package once gnucap-default-plugins1 (without the "1",
effectively destroying libgnucap0) is being installed

instead of

/usr/lib/$MULTIARCH/gnucap0/gnucap-default-plugins.so

i could use

/usr/lib/$MULTIARCH/gnucap/gnucap-default-plugins0.so

but that requires non-upstream style name mangling, and breaks data
files (the path is an environment variable, plugin names aren't).

> Looking at the build and binaries that are created I would suggest the
> following packages for now.
> 
> gnucap
> gnucap-default-plugins
> libgnucap-dev
> libgnucap0

pardon my ignorance. it simply does not work.

the headers are required to use gnucap. another program that links to
libgnucap0 will break as soon as gnucap receives an upgrade.

the proposed layout has a "0" in libgnucap0. the idea is to have
multiple versions of libgnucap installed (and not break reverse deps),
but libgnucap-dev still breaks them.

replicating what singular does, i get one more package.

gnucap                 (singular)
gnucap0-dev            (libsingular4-dev-common)
libgnucap0             (libsingular4)
libgnucap0-dev         (libsingular4-dev, depends on libsingular4-dev-common)
gnucap-default-plugins (singular-modules)

fixing the issue with the upgrade path, and removing the unnecessary
version in libgnucap0-dev, i get

gnucap
gnucap0-dev
libgnucap0
libgnucap-dev (depends on gnucap0-dev, no need for a "0" here)
gnucap-default-plugins0 (need a version here!, see above)

with this layout, gnucap-modelgen would have to go back to gnucap.
fingers crossed, let's hope that nobody uses it (?).

cutting down the count i could go with

gnucap
gnucap0-common (gnucap-dev + versioned default plugins) <<=== !
libgnucap0
libgnucap-dev (depends on gnucap0-common)

now thats weird, because libgnucap-dev depends on a non-header package.
is this allowed and any better?

i left the libgnucap-dev package in, as this is the convention for "the
package required for the purpose of linking to libgnucap"). i could
remove it, end up with 3 packages. that is against my intuition,
possibly also against the guidelines.

i will implement this, as soon as we agree on a variant. i hope the
singular package provides justification for the unconventional header
package.

> You could also improve the readability of the long descriptions like
> this way.

will do. thanks.

regards
felix

[1] http://git.savannah.gnu.org/cgit/gnucap.git/log/?h=autotools-1