[Pkg-electronics-devel] gnucap package.

[Carsten Schoenert]

Hello Felix,

Am 14.04.2018 um 11:57 schrieb Felix Salfelder:
>> 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.

pkglibdir is used/introduced by the Autotools and is pointing to
/usr/lib/$package on default, Debian has introduced the Mulitarch
behavior starting with the Wheezy release. As small but important
difference. But no need to ride the bullet here.

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

Now we are back in the circles for the second time. :-/
O.k., you built two packages gnucap and gnucap-default-plugins0 and you
let the former package depend on the latter, means the latter will
*always* be installed once somebody is installing gnucap.

What is the gain of the package gnucap-default-plugins0 without gnucap?
What can I do with this package? I'd say quite nothing. So why create
this package and not install the plugins within the gnucap package? As
you more familiar with the usptream source we two know why the plugins
are built separately.

And you mentioned libgnucap, yes someone can use the plugins through
this library. But this is no reason to let the plugins be a hard
depending package for gnucap itself as then I can use gnucap without the
plugins.

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

Which applications? Are they packaged in Debian? And if so it would be
good the package would suggest them. You don't have any Suggests on
gnucap-default-plugins0 nor get you some information about the usability
within the long package description of the plugins in other packages.

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

If you now doing argument this way we could have saved a lot of times
and given you can really build two dedicated packages (one for gnucap
and one for the plugins) you make at least the plugins package mostly
useless by this Depends.

The solution is really simple, answer yourself the question if gnucap
can work without the plugins? Whenever the answer here is yes, a Depends
is wrong.
I'd say yes, as if not, why not to include the functionality directly
within the gnucap package? Also if the answer is yes than
gnucap-default-plugins0 can't be a Depends, but it's fine to recommend
instead of suggest the package then.

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

Looking at your control file I don't see any recommended packages on
gnucap-default-plugins0 nor reverse dependencies on gnucap. So what do
you want to solve here? You do the packaging of gnucap, not for other
packages. If other package have wrong Depends or Recommends this is for
sure a bug in the other packages.

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

No. Again, installing Recommends is the default on Debian systems after
a installation. Means, if gnucap is now recommending
gnucap-default-plugins0 this package will be installed automatically if
users update this package. On server systems the installation of
Recommends is mostly turned of by the admins, but on typical desktop
system not.

> So I dont think the Depend is useless. see above -- i must
> misunderstand something.

Maybe not useless, but wrong in my eyes. You probably don't see the
difference between depending and recommending. A depending package is
*essentially* needed by the meaning in the policy, means the package
isn't really usable without this package. We mostly have in Debian
probably to much packages that are depending but do not really need
this. So it's really good to think twice if a Depends is really really
needed. Let me point again to README.Debian ...
And if you really want to inform the user about some really important
changes there is also the possibility to add the news into NEWS. But not
needed here I'd say.

And, there is wiki.debian.org if like a more central place.

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

Don't care here (in src:gnucap) about other packages, make bug reports
against other packages if you think the issue is important.

> Can we possibly postpone this?

And upload a package to NEW which has some important or not cleared
packaging issue? Not a good idea in my eyes. Explain me and to the users
why you want to have gnucap-default-plugins0 as a hard depending package
on gnucap and we will come together. Currently I don't see the point yet
as we have discussed about the plugins etc. and versioning of them in
the past.

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

Fine.

Btw, libgnucap-dev needs some small addition to the short description,
otherwise it looks like there is something forgotten.
Maybe "GNU Circuit Analysis package, development library"

-- 
Regards
Carsten