[Pkg-electronics-devel] gnucap package.

Carsten Schoenert c.schoenert at t-online.de
Sat Apr 14 08:47:00 BST 2018


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?

>> But I'd like to get a more informative debian/changelog file for the
>> upload, I can try to provide additions I'd make based on the commit
>> messages in the past.
> 
> i added a few more bits to the changelog. let me know if something is
> unclear.

It's better than before but still a very "telegram'd" style, at least
for a package that will get an upload after along time with slightly
more changes.
Please keep in mind the user is typically not looking into the packaging
of the package, based on the rules for Debian I even not needed to make
that public, so the changelog is beside README.Debian the only place a
user can get information about the package and the changes to it, I try
to keep this file as informative as possible. And this makes a lot of
sense I think. The persons which will read this for this upload are the
ftpmasters as there a new packages. And they need to judge about your
package, as faster they understand your changes and modification the
will accept them.

Please see also

https://www.debian.org/doc/manuals/developers-reference/ch06.en.html#bpp-debian-changelog

Entries I really would still modify.

>   * libgnucap0 + libgnucap-dev (Closes: #224467)
>     enables custom executables or future packages using the library

What's with these packages? Both are new and the change can be explained
a bit more.

> -  * libgnucap0 + libgnucap-dev (Closes: #224467)
> -    enables custom executables or future packages using the library
> +  * added new packages libgnucap0 and libgnucap-dev
> +    Adding the the new library package libgnucap0 and the package
> +    libgnucap-dev enables. Both packages providing the possibility to build
> +    custom binaries by users with using features of gnucap without the need
> +    to install the whole gnucap based packages and files.
> +    (Closes: #224467)

...

>   * split off gnucap-default-plugins0 package
>     + binary plugins
>     + soname dependent pkglibdir

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

> root at x260:/build/gnucap-0.36~20171003# find debian/gnucap-default-plugins0  -type f 
> debian/gnucap-default-plugins0/DEBIAN/md5sums
> debian/gnucap-default-plugins0/DEBIAN/control
> debian/gnucap-default-plugins0/usr/share/doc/gnucap-default-plugins0/copyright
> debian/gnucap-default-plugins0/usr/share/doc/gnucap-default-plugins0/changelog.Debian.gz
> debian/gnucap-default-plugins0/usr/share/doc/gnucap-default-plugins0/changelog.gz
> debian/gnucap-default-plugins0/usr/lib/x86_64-linux-gnu/gnucap0/gnucap-default-plugins.so

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

>   * man pages for the three executables. these are no longer upstream.

The same here, new or re-added I assume. What man pages?

>   * get-orig-source, snapshotting upstream git

Likewise, reworked, added, ...?

>   * debian/control: Bump Standards-Version to 4.1.3

Are there changes needed? And if we are by the Standards-Version a new
policy version was released, time again to update.

https://www.debian.org/doc/debian-policy/#version-4-1-4

>   * remove Wesley from Uploaders (Closes: #759987)
>     thanks for your work on this package!
>   * remove Hamish from Uploaders (Closes: #831480)
>     thanks for your work on this package!

Could be condensed.

> -  * remove Wesley from Uploaders (Closes: #759987)
> -    thanks for your work on this package!
> -  * remove Hamish from Uploaders (Closes: #831480)
> -    thanks for your work on this package!
> +  * remove Wesley  J. Landaker and Hamish Moffatt from Uploaders as they not
> +    active anymore
> +    Thanking both for their work on the packages of gnucap in the past!
> +    (Closes: #759987, #831480)
>    * 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.

> -  * lintian override http in watch file
> +  * adding a lintian override for http URL in watch file
> +    Lintian is complaining about the usage of http:// instead of https:// on
> +    the URL http://gnucap.org/archive/ in the watch, a file for automatic
> +    checking for new upstream versions.
> +    gnucap.org isn't using the https protocol (yet or never will) and we need
> +    to use http 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! 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.
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.

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.

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.

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

Please have a look a the paragraph about Depends in the policy ans ask
yourself if this depends is really needed.

https://www.debian.org/doc/debian-policy/#binary-dependencies-depends-recommends-suggests-enhances-pre-depends

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

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.

-- 
Regards
Carsten



More information about the Pkg-electronics-devel mailing list