[Pkg-electronics-devel] gnucap package.

Carsten Schoenert c.schoenert at t-online.de
Mon Mar 26 21:13:49 UTC 2018



Am 26.03.18 um 02:14 schrieb Felix Salfelder:
....
> yes. gnucap also does not add a 0 into the soname. i was assuming that
> this would be my job (as a packager). upstream does not make any attempt
> to prevent misuse on this level, that includes the choice of the install
> paths or config file names.

I will try to strike out a bit ...
Some years ago I wanted to package libcoap but gave up on this because
libcoap was not using any build system and had hard coded all the magic
(well, that was quite zero) for the library installation inside the hand
crafted Makefiles.
There was no versioning existing. There was no pkg-config stuff, there
was no support for Multiarch. I realized quickly that maintaining such a
Debian package will became PITA over the time. So I decided not to
package this peace of software and contacted the upstream author what
options for creating a build systems the creator of libcoap was seeing.

We concluded the Autotools would be the preferred system and I was
working for some weeks on the migration of the existing system. We now
have a configure.ac file were all the variables exist to create various
new releases with new ABI versions.

>From a POV of now it was the best decision we could have done. We have
found a lot more contributors and maintaining libcoap now is much easier.

For ABI/API compliance we decided we don't want to a accept any API
breakage in the future, this means simple that even newer header files
and newer library will never break old binaries, old binaries which are
linked against a older version of libcoap will also work with newer
libraries. By this I as Debian maintainer of this package won't ever
need to think about updating the package to newer library versions.

What I want to see here, upstream need to think about future versions
and functionality soon as possible while developing the source not only
because of the linux distributions.

Right now gnucap has no versioning, all symbols don't have a version no
matter how you as upstream name the library, libgnucap0.so or
libgnucap50.so doesn't matter.
dlopen will use the first symbol that is found in the search order. If
the symbols have versions dlopen is searching for the required version
too. But even for this you would need to add a full version to the
linking of your library.

The tool in the Linux world for this is libtool. You can call it
manually in your Makefiles, but I'm to stupid for this and we simply use
the m4 macros in the autotool environment in the libcoap package.

But this all helps us not really right now to find the correct package
layout for gnucap. ...

...
> the functionality of pkg-config is in /usr/bin/gnucap-conf (just without
> the dependency on pkg-config). i put the config file to /etc, which
> turned out to be wrong, as it would break (at least) multiarch, which
> pkg-config files do not break.

[offtopic]
I will never really understand why people always try to be smarter than
long existing tools and try to develop own intelligent tools.
I've seen this approach often but mostly it's not really needed to to this.

...
>> 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.
> 
> if the headers end up in libgnucap-dev (which i am arguing against),

-dev packages are the package were headers have to go to if they are
needed to develop other binaries. :)

> then it will be totallt impossible to co-install them. this will become
> necessary once somebody has linked against libgnucap.

No.
See above, you need to think about the meanings of ABI and API! And if
you have understand that fully you also see why a API shouldn't never be
broken by updates. If you never break the API you also don't need to
think about various header file versions if you it right.
And if you need to change the API version you better change the also
place there your new shiny header will be found.

Take a look at the libpng project e.g.

https://packages.debian.org/sid/arm64/libpng12-dev/filelist
https://packages.debian.org/sid/amd64/libpng-dev/filelist

...
> gnucap-modelgen. turns .model files into .cc and .h. i'm not sure if the
> current package installs it, or what the manual says. the .cc and .h
> files are obviously useless without the gnucap headers in place.

So a "arbitrary" user doesn't need gnucap-modelgen ...

> the headers are needed/used to compile binaries ("plugins"). but these
> binaries are not associated/linked to a shared library.

The "arbitrary" user also don't do this?

> binary compilation happens in the course of "using gnucap" not just
> during "development".

There is a difference of using and developing, this difference is mostly
also taking affect for the packaging. The classical (arbitrary) user
don't want to develop something, he will just use a tool. Well, at least
this is my POV. It's ok if you disagree in the sentence of gnucap.

...
>> 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.
> 
> if gnucap-dev does not qualify as a proper -dev package, i'd be happy to
> call it gnucap-common.

That's possible of course as a arch:any package then.
...

>> 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.
> 
> i'm a bit worried that nothing in gnucap will hold the user back from
> loading binary incompatible plugins. which may lead to random results.
> with that extra "0", it will be a bit harder to do that accidentally.
> it looks like just a safety net. but with libgnucap-default-plugins1 i
> will need the version there anyway.

No dlopen + ldconfig works different. See above.
These are all problems upstream need to solve, the packaging can't do that.

...
>>> gnucap
>>> gnucap0-dev
>>> libgnucap0
>>> libgnucap-dev (depends on gnucap0-dev, no need for a "0" here)
>>
>> Why no '0' then here?
> 
> when i link (or package) another gnucap executable, why would i not want
> to use (or depend on) the newest library version? libgnucap-dev reflects
> my understanding of how it is usually done.

My question was related to your package 'gnucap0-dev', if you use '0' on
this other hypothetical package than you need to do this on the other
-dev package.

> to summarise:
> - using gnucap requires headers that must (sufficiently) match the api
>   of the library the executable is linked to. ideally they never change,
>   but that might be wishful thinking. current work in progress changes
>   (yet irrelevant) subtleties. who knows?

As long as you don't change the version you also shouldn't change the
API. If you will need to do that please really have a look at libtool
which will help you to have correct version numbers.

> - developing gnucap programs need linking with -lgnucap. these programs
>   should/must not break upon a library api/abi upgrade.
>   arguably "recompile/relink your programs" seems to be very common
>   outside debian. i won't recommend to build a production environment on
>   this.

We are going in circle ways ...

If I have understand your various emails now correctly I would do the
following package names.

gnucap:
the gnucap binary, man page etc., depends on gnucap-common

gnucap-common:
the header files

gnucap-devel:
the binaries gnucap-modelgen and gnucap-conf, depending on gnucap-common

gnucap-plugins-defaults0:
the default plugins, depends on gnucap

libgnucap0:
the public library

libgnucap-dev:
the library development file, depends on gnucap-common

All the depends need to be versioned depends like mostly existing.
gnucap-devel could also be dropped and moved into gnucap if you prefer.

-- 
Regards
Carsten Schoenert



More information about the Pkg-electronics-devel mailing list