[Pkg-electronics-devel] gnucap package.

[Felix Salfelder]

Hi Carsten.

this seems to be converging.

On Mon, Mar 26, 2018 at 11:13:49PM +0200, Carsten Schoenert wrote:
> 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.

i have tried to push libtool versioning upstream. to no avail.

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

long existing. just a fun fact (from wikipedia).

libtool, first released 1997
gnucap, first released 1993

it might explain (not saying justify) the situation.

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

there's some indication that this is being "done right". there's just no
guarantee.

> And if you need to change the API version you better change the also
> place there your new shiny header will be found.

i don't know how to get out of this easily. maybe a larger
user/developer base will some day agree on interface versions whichever
way, and maintain that.

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

it's a safe assumption. modelgen is a precursor of verilog. a followup
gnucap-modelgen-verilog will change issues.

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

currently, the default plugins are installed as binaries. that might
change -- maybe it will solve most of the trouble we got into here.

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

good!

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

i certainly agree on the library version, libtool and such.

i need to read up on these versioned symbols, in the context of plugins.
perhaps a good reason to push for libtool again. if it magically works,
i'd be inclined to maintain the autotools branch, particularly the
triplet...

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

maybe. i don't see it. maybe it's no longer relevant.

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

i think there is a catch. if a library upgrade removes a symbol, e.g. by
moving some functionality to "plugin space", then an old plugin using
that symbol can impossibly work as intended. even if the symbol exists
in some other place. i bet that upstream is aware of this.

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

yes. i understand that it will be safe to attribute breakage to
upstream. such as breakage induced by a new library version. fingers
crossed.

under what circumstances would the package switch from libgnucap.so.0 to
libgnucap.so.1?

> 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: some binaries
> gnucap-plugins-defaults0: the default plugins, depends on gnucap
> libgnucap0:
> 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.

i will probably do that. i need to roll back and understand what the
difference to my first variant was (besides -common vs -dev).

many thanks
felix