[Pkg-electronics-devel] gnucap package.

[Felix Salfelder]

On Sat, Apr 14, 2018 at 09:47:00AM +0200, Carsten Schoenert wrote:
> Hello felix,
> 
> Am 13.04.18 um 11:13 schrieb Felix Salfelder:
> >> Otherwise we could also upload to unstable if you feel the code is ready
> >> for a broader base of users.
> > 
> > i have no doubt that the *code* is as tested and stable as it can be.
> 
> so you'd like to see it in unstable then?

Yes, i think that is sensible. given that the packageing does not break
things. i am beginning to be confident that it will not.

> >> But I'd like to get a more informative debian/changelog file for the
> [..]
> Entries I really would still modify.
> [..]

Added more text, thanks for your suggestions.

> That's an example there I don't get your point. What do you want to say?
> The package only contains one file. pkglibdir = /usr/lib/$package !=
> /usr/lib/$multiarch_architecture
>
> > debian/gnucap-default-plugins0/usr/lib/x86_64-linux-gnu/gnucap0/gnucap-default-plugins.so

when i set pkglibdir to /usr/lib/x86_64-linux-gnu/gnucap0 in an
autotools build system, then this is where the .so is ending up.
so in my head, "pkglibdir=/usr/lib/x86_64-linux-gnu/gnucap0" is the
assignment i did. I rephrased it without using the word pkglibdir.

> >   * gnucap-common package (Closes: #693267)
> >     this package provides the headers, required to load (some)
> >     plugins at run time
> 
> Whats with this package? Is it new and added or moved over from a other
> package? Please keep the first characters of the explanations as for
> sentences too always in a upper letter. That's the grammatical rules for
> English. I'd like again point to the developers reference section about
> the changelog file from above.

okay, rephrased.

> >   * man pages for the three executables. these are no longer upstream.
> [..]
> >   * get-orig-source, snapshotting upstream git
> [..]
> >   * debian/control: Bump Standards-Version to 4.1.3

added more to these.

> Could be condensed.

thanks. i wasn't fully aware of the syntax.

> >    * lintian override http in watch file
> 
> A user will probably not know what Lintian or the watch file is so some
> more explanation is better here I think.

I see your point. I have changed it to be user comprehensible.

> In commit 66b441e36a19410186a24e99f61860d8eeeeb8a8 you have added
> gnucap-default-plugins0 as a Depends to gnucap.
> This make the package itself mainly useless as nobody can use it as
> standalone and gnucap will always pull in this package!

but this is exactly the intent. in the previous gnucap package, the
binary plugins were linked into the main executable. this is no longer
the case. I can now
- tell gnucap not to load them.
- not install the "gnucap" package, and still use the plugins
  (e.g. through libgnucap).

Still I want "gnucap", to provide what it did in the past.

> Both packages
> are Arch: any and platform depended, so it makes no reals sense to build
> this two packages while one is always depending on the second while this
> second package is useless as standalone package.

No. the second package is essential to other applications.

> Even as Recommends the package will automatically pulled if the system
> is installing Recommends. Note this this is the default if you do not
> change this after the installation.

I am aware of this. however, only the depend guarantees that after an
upgrade, gnucap (the package) operates as it did previously.

> As reason you wrote:
> 
> >     actually, that's a recommend. but only with these plugins, the new
> >     gnucap package will seamlessly replace the old one.
> 
> So you only have made this to get a proper update? If yes this is the
> wrong way, if you need to to something like this we have
> Breaks/Conflicts/Replace for doing such things.

that would mean, turn that Depend into a Recommend, and update all
reverse dependencies to also depend on the default plugins? it does not
seem to be worth the trouble. or i misunderstand something.

> In my eyes this commit is not needed and useless, the last version in
> Debian only provides the binary package gnucap so there is no transition
> of packages needed.

Without the Depend, it will leave users without the plugins. So I dont
think the Depend is useless. see above -- i must misunderstand
something.

> What you want to do here is adding gnucap-default-plugins0 as a Suggests
> to gnucap instead of Depends.

"Suggest" (the weaker one) is also fine with me. Would also require
changes to other packages.

Can we possibly postpone this?
Perhaps I can do it in a fully reasonable way, once gnucap-conf is in
gnucap-common (and implemented with pkgconfig). currently it's a bit in
limbo anyway, as you noticed.

> The file README.Debian is the right place to explain the user important
> notes about the package(s) and their relationship if needed.

I will write this file, and get back to you.

> You have applied my previous patch about the missed ${shlibs:Depends}
> for gnucap. May i ask why you dropped the complete patch description and
> modified it to a really less declarative one?
> 
> The main purpose of a commit message is to describe why the change was
> done, this is now lost.

apologies if I messed this up. I considered the missing depend as an
obvious mistake i made in one of the previous commits or during the
rebase. in your patch quoted below, i cannot find any further commit
message you are referring to. iow, i don't get it.

> diff --git a/debian/control b/debian/control
> index 3b19f9b..2811f83 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -28,7 +28,7 @@ Description: GNU Circuit Analysis package, the
> library
>
>  Package: gnucap
>  Architecture: any
> -Depends: ${misc:Depends}
> +Depends: ${misc:Depends}, ${shlibs:Depends}
>  Recommends: gnucap-common
>  Description: GNU Circuit Analysis package, main executable
>   GNUCAP is a general purpose circuit simulator. It performs nonlinear

thank you very much for your feedback!

cheers
felix