[Pkg-electronics-devel] gnucap package.

[Carsten Schoenert]

Hi Felix,

Am 19.03.2018 um 14:06 schrieb Felix Salfelder:
...

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

That's correct, and I don't want to talk about build systems, they
doesn't matter in the context of one or more *.deb files. The maintainer
is responsible for the correct content of the Debian package files
(.deb) in the end.

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

No, the intention of this -dev-common package is a bit different to what
you want to solve.

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

You are here talking about installing possible multiple ABI versions of
a shared library. Yes, at one point you need to think about such
constellations, but not right now for gnucap.
Of course this is possible, but the upstream source need to provide a
installation of the files and folders in a way it's usable and doesn't
conflict with previous project versions. That mostly means you also will
need versioned symbols within the library (gnucap doesn't do this right
now).

A simple example.
Given you have a package 'mybin' that is installing a binary 'mybin' and
also libary+header files with an internal version ABI version 0.

/usr/bin/mybin
/usr/include/mybin/*.h
/usr/lib/mybin.so.0.0.0
/usr/lib/pkg-config/mybin.pc

For me later as a developer who wants to use the dev files I'm happy to
find a pkg-config file which holds all information I need, like
depending other libraries, path to the header files and so on.

Now you create a new much better version of 'mybin' with a ABI change
but doesn't take care about the correct versioning for the library. With
which name will the library installed and were? Where will the header
files go to, which have of course different prototypes for the functions?

Yeah, that is a point every upstream project will come to at one day and
if they do it right this is all no problem. But I don't see gnucap here
in the next time. So you don't need to really take care for something
that isn't a problem currently And even if gnucap comes one day as
gnucap1, it's not problem to co-install more than one version of the dev
files.

/usr/include/mybin1/*.h
/usr/lib/mybin.so.0.1.0
/usr/lib/pkg-config/mybin1.pc


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

According to the debhelper sequence you currently install the gnucap
header files and a c++ source file. What is the model compiler?

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

Then they are no development files. The intention of -dev packages is to
provide all the development files which are needed to create own
binaries and/or shared libraries.

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

Sorry I can't follow that. I've tried to find some information related
to your statement on the current wiki [1] for gnucap. It explaining the
plugin model that is used, the mechanism that is used for that is
exactly what I've written about in my previous email.

The binary is loading a shared object file (simply because your work is
based on the STL and own written functions which are build with a C++
compiler), but no plain text files (like a header file). I also haven't
seen such a function in the source. So maybe I oversee something totally
or we are talking from completely different things. But we don't need to
dig here into the internal details of loading plugins or other things.
With a technical view from the Debian side the header files are "just" a
depending package.

If your binary need such a header file for what ever reason, but this
header file isn't needed as a development file, then it doesn't belong
to the -dev package but to the binary (or a extra) package.

What does now the singular package?

There is libsingular4-dev and libsingular4-dev-common.
The latter is a package with arch:all, the former is arch:any due the
platform specific build of the libraries. This is done to decrease the
package size of libsingular4-dev which is platform specific.

libsingular4-dev-common is holding all the files that are the same on
every platform, so it needs to be built only once and not for every
platform Debian is providing a release. The maintainers could have
dropped this and building only libsingular4-dev packages which are
bigger and specific to the platform which they are build.

But these two packages have nothing to do with the reasoning you have
given on your package layout for gnucap, sorry I still don't see this.
You could do the same for gnucap (building a -dev-common package) but
given to the size of gnucap and the additional initial work for this I'd
hardly to consider to not to do this now.

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

What is a source version?
I guess you mean a simulation model? If so we are talking again about
development files. If a user is building own plugins they are built as a
shared object file.

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

I don't hang on the non usage of this prefix '0', if you want to use it
related to the '0' on the libgnucap0 package I'm fine with this.

...
>> gnucap
>> gnucap-default-plugins
>> libgnucap-dev
>> libgnucap0
> 
> pardon my ignorance. it simply does not work.
> 
> the headers are required to use gnucap.

strace is telling me something different, but any way. ;)

> $ strace -Tfe trace=read,access gnucap
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory) <0.000047>
> access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory) <0.000042>
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory) <0.000022>
> read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\245\2\0\0\0\0\0"..., 832) = 832 <0.000021>
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory) <0.000030>
> read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\300\10\0\0\0\0\0"..., 832) = 832 <0.000021>
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory) <0.000024>
> read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\271\0\0\0\0\0\0"..., 832) = 832 <0.000024>
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory) <0.000033>
> read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300*\0\0\0\0\0\0"..., 832) = 832 <0.000020>
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory) <0.000024>
> read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\33\2\0\0\0\0\0"..., 832) = 832 <0.000023>
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory) <0.000024>
> read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\16\0\0\0\0\0\0"..., 832) = 832 <0.000020>
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory) <0.000006>
> read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200f\1\0\0\0\0\0"..., 832) = 832 <0.000005>
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory) <0.000006>
> read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\321\0\0\0\0\0\0"..., 832) = 832 <0.000005>
> Gnucap : The Gnu Circuit Analysis Package
> Never trust any version less than 1.0
> Copyright 1982-2013, Albert Davis
> Gnucap comes with ABSOLUTELY NO WARRANTY
> This is free software, and you are welcome
> to redistribute it under the terms of 
> the GNU General Public License, version 3 or later.
> See the file "COPYING" for details.
> main version: master 2017.10.03
> core-lib version: master 2017.10.03
> access("/etc/gnucap.rc", R_OK)          = -1 ENOENT (No such file or directory) <0.000010>
> access("/usr/lib/x86_64-linux-gnu/gnucap0/gnucap-default-plugins.so", R_OK) = -1 ENOENT (No such file or directory) <0.000007>
> load gnucap-default-plugins.so
>      ^ ? plugin not found in /usr/lib/x86_64-linux-gnu/gnucap0
> +++ exited with 0 +++

gnucap seems to lack a recommends or at least a suggest on the plugins.

...

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

Why no '0' then here?

> gnucap-default-plugins0 (need a version here!, see above)

Well, if you use a ABI version on the -dev package then please continuously.
-dev packages not necessarily ned to have the ABI version in their name.
libfoo-dev means always this is the most recent package version. And if
there is just one ABI/API version packaged it's not needed to add a
version number.
If a new ABI/API version 1 is introduced you will always introduce a new
binary package which then will have a virtual package libfoo-dev which
depends on libfoo1-dev if needed. Or it is only providing libfoo1-dev,
the user can install both binary packages if wanted, the old libfoo-dev
and libfoo1-dev.

Your comparison to singular isn't fully fitting.
your gnucap0-dev != libgnucap0-dev-common

To come to an end, if you want to create such a dev-common package just
do it, you are the maintainer and you need to answering packaging
question and to bug reports as well if arising.
Keep reminded such a -dev-common package is typically arch:all.

I just tested a bit with a installation of your current package set up
and I can run the binary gnucap if I install the packages gnucap,
gnucap-default-plugins0 and libgnucap0. So I stay in principal on my
previous suggestions for the binary package names. If you want to split
of the existing -dev package you can do this. I would drop this.

gnucap
gnucap-default-plugins0
libgnucap0
libgnucap-dev
(libgnucap-dev-common)

If gnucap-modelgen is needing some header files (the man page isn't
mention this) I would create a own package for this binary with a
depending on package libgnucap-dev.
Even gnucap-conf isn't probably needed for the plain cli mode of gnucap
and could go into the same package or into libgnucap-dev, it's more
useful for development constellations?

> 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) <<=== !

Would be a unusual constellation, -common packages are arch:all normally.

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

Not really.

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

Mhh, this would all not be as I would expect the package names. gnucap
isn't that special to other existing science packages I think.

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

In the end it's mostly to find a package layout which brings for the
users dedicated and customized content of the binary packages and OTOH a
not complex and flexible maintenance for the maintainer.
I'm sure we will find some conclusion how to do this for gnucap.

[1] http://www.gnucap.org/dokuwiki/doku.php/gnucap:about

-- 
Regards
Carsten Schoenert