[Pkg-electronics-devel] gnucap package.

[Carsten Schoenert]

Am 10.03.2018 um 00:43 schrieb Felix Salfelder:
> Hello Carsten.
> 
> On Fri, Mar 09, 2018 at 09:18:33PM +0100, Carsten Schoenert wrote:
>> I'm a bit concerned about the current structure of the -dev packages, so
>> far I see it's not worth to split out all theses development packages.
>> gnucap is small and not widely used, I think it's nit really worth to
>> have two dev packages.
> 
> shall i rename gnucap-dev to gnucap-common? it's not really a dev
> package, but that will become more clear when the jit compiler will be
> available. the jit compiler does not require libgnucap-dev. somehow it
> will have to use headers that match the driver. my hope is, that future
> headers will be backwards compatible. chances are, they will. the
> library will not be.

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.

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.
This describes what the development package needs to do and what it is
for. If you would build more than one public library and wanted to
create a own library packages for this you would also need to create a
separate development package for this (if this is really needed).
Mostly this is a bit overkill for no real gain, you have more packages
you need to understand. Mostly the package maintainers just create a
package 'mypackage-libs' and 'mypackage-dev' to keep the complexity also
for the users low.

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

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.

> strictly, *some* headers are not needed for the jit compiler, and others
> may not be needed to link new programs. sorting that out will require
> more thought.
> 
> 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.

>> libgnucap-dev has no header files for example. How could I include
>> prototype definitions if I want to build a binary which will be linked
>> against libgnucap0?
> 
> 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.

You now do not win anything if you create such a package construct.
Without asking other DDs I wouldn't upload this to NEW. If you disagree
you should write to debian-devel and try to convince other package
maintainer from your logic. I've a other point of view, see further down
why.

> (it became more obvious to me that gnucap-modelgen must go to
> gnucap-dev, this is now fixed).
> 
>> Maybe you can drop libgnucap-dev and keep only gnucap-dev? But I really
>> don't understand the gnucap package that much to give right now a good
>> advice here. Unfortunately I haven't enough time to dig into this for now.
> 
> the -dev packages serve entirely different purposes. i would like to
> avoid this kind of oversimplification.

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

> also if at the current stage it's
> just for clarity.  i cannot find a place for the library symlink better
> than libgnucap-dev, which i would (as a user) not normally install, as
> usual.

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

> the difference to some other packages is, that gnucap allows to
> transparently load plugin source code (such as generated from verilog)
> from the user front end (schematic editor, whatsoever). this requires
> the headers i put into gnucap-dev.

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

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 don't see how the number of users is relevant. most of gnucap can not
> even be built against the current package. why should anybody want to
> use it right now?  (yes, there is gcompris..)

The count of user is not important, that's correct. But on the other
side you don't need to make it more complicated than needed. You just
need to satisfy the policy.

>> #802307 can be closed directly in my eyes, no feedback from the reporter
>> within 2 years ...
> 
> how can i do that? (does it not require any privileges?)

As you have already found out how to handle this you have seen that
every person which can create a correct addressed email with some
correct content I think this needs no further explanation.

bugs.debian.org describes the possible command and use cases for
manipulating bug reports. To understand what the command are doing
please have a look at existing bug reports and also at the emails that
have bug reports closed.
Please try to always add a Version to the bug tracking system if you
close a report. A exception for this can be done in a case like this one
here.
To see which bug reports are solved with which versions over the various
Debian releases adding a version helps a lot.

So, right now I see the remaining question about the binary packages
need to be solved.

Looking at the build and binaries that are created I would suggest the
following packages for now.

gnucap
gnucap-default-plugins
libgnucap-dev
libgnucap0

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

> $ git diff
> diff --git a/debian/control b/debian/control
> index b56672c..642978e 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -35,6 +35,7 @@ Description: GNU Circuit Analysis package, main executable
>   dc and transient analyses, Fourier analysis, and ac analysis
>   linearized at an operating point. It is fully interactive and
>   command driven. It can also be run in batch mode or as a server.
> + .
>   This package contains a main executable and gnucap-modelgen.
>  
>  Package: gnucap-dev
Why is gnucap recommending 'c++compiler', this package isn't existing.
Why is this package trying to recommending a C++ compiler at all, that
makes no real sense for binary package that is 'just' used by users.
Also gnucap doesn't need gnucap-dev, at least not a -dev package
described by policy.

If change the Build-Depends of debhelper (>= 11) to (>= 11~) you make it
easier to create a backport of this package later and keep the control
file equal for booth releases.

-- 
Regards
Carsten Schoenert