[Pkg-electronics-devel] gnucap package.

Felix Salfelder felix at salfelder.org
Fri Mar 9 23:43:07 UTC 2018


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.

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.

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

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

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

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

> > There's also
> >   * Fix FTCBFS: Add gnucap:native to Build-Depends. (Closes: #-1)
> > 
> > is that correct for "nobody cared about writing a bug report"?
> 
> You need to fix the bugnumber in debian/changelog here.
> s/-1/878364

okay. there are more bugs listed under bugs.debian.org/src:gnucap. i did
not see that from bugs.debian.org/gnucap. feeling stupid now.

> reports, the trigger is 'Closes:' not 'Close'.
> $ git diff
> diff --git a/debian/changelog b/debian/changelog

imported

> And it's always a good tone to thank the people for their work on the
> package if they gonna removed from the uploaders list. :)

done.

> What about #831480? Could be added to the changelog as well if Hamish
> Moffatt is removed from the uploaders.

done.

> So you would have covered all existing reports finally.

thanks for your help.

cheers
felix



More information about the Pkg-electronics-devel mailing list