Bug#925911: RFS: lopsub-1.0.2 [ITP]

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#925911: RFS: lopsub-1.0.2 [ITP]

Andre Noll
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "lopsub":

 * Package name    : lopsub
   Version         : 1.0.2
   Upstream Author : Andre Noll <[hidden email]>
 * URL             : http://people.tuebingen.mpg.de/maan/lopsub/
 * License         : (L)GPLv3
   Section         : libdevel

It builds the following package:

lopsup - The Long Option Parser for Subcommands

To access further information about this package, please visit the
above URL.

About lopsub: It's not a new idea to provide a library for parsing
command line options as there are libargtable2 and gengetopt which are
conceptually similar. Nevertheless, here is yet another option parser
which was written already some years ago. Compared to the existing
option parsers, lopsub offers a couple of additional features, for
example support for subcommands and direct man page generation.
It is actively maintained, yet mature, and the API is stable and
well documented.

Although no debian packages use the lopsub library so far, it makes
sense to get this in because (a) it makes life easier for people who
want to use software that depends on lopsub [1], and (b) it paves the
way to debianize those software packages as well. Moreover, lopsub
is tiny and has no build dependencies other than a C compiler, flex
and m4. The binary package has no dependency other than libc.

This is my first attempt to get a package sponsored, and also my
first attempt to create a debian package. I've tried to address
the issues listed in the docs and I believe the package is ready
for upload. However, there are still some warnings from lintian
I don't know how to deal with. While there is certainly some room for
improvement, I'm confident that the remaining issues can be addressed
easily.

You can grab a copy by running

        git clone git://git.tuebingen.mpg.de/lopsub.git

This will get you three branches: master, pu, and t/debian

The t/debian branch contains a single commit on top of master which
adds the debian/ directory with the usual files in it. The commands

        git checkout origin/t/debian
        dpkg-buildpackage

should build the debian package as expected. This has been tested
on debian-9 and debian-10.

This package is known to compile and work on Debian and Ubuntu Linux
(x86_64, x86_32, armv6l), FreeBSD-12.0 (x86_64) and NetBSD-8.0
(x86_64).

Thanks
Andre
---
[1] http://people.tuebingen.mpg.de/maan/
--
Max Planck Institute for Developmental Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#925911: RFS: lopsub-1.0.2 [ITP]

Adam Borowski-3
On Thu, Mar 28, 2019 at 11:41:45AM +0100, Andre Noll wrote:
>  * Package name    : lopsub
>    Version         : 1.0.2

Such a version means a native package; only software written specifically
for Debian which makes no sense outside it should use the native format.
Even if you're both upstream and the packager, a non-native format is
helpful in case someone other than you would upload a fix.

This library is certainly not something for Debian only, thus please append
"-1" to the version, and set debian/source/format to "3.0 (quilt)" (which,
despite the name, doesn't require actually using quilt).

>    Upstream Author : Andre Noll <[hidden email]>
>  * URL             : http://people.tuebingen.mpg.de/maan/lopsub/
>  * License         : (L)GPLv3

It would be nice to mention more prominently what parts are GPLv3-ed and
which are LGPLv3-ed.

>    Section         : libdevel
>
> lopsup - The Long Option Parser for Subcommands

> However, there are still some warnings from lintian
> I don't know how to deal with.

I'd recommend running "lintian -i" which gives a long descriptive message
for every warning, including hints how to fix.

I see a static library installed by the package.  Those shouldn't generally
be used unless you're doing something special -- static linking makes
security and bugfix updates extremely tedious.  Libraries should also be
split into separate binary packages, with lib${name}dev providing
development files while lib${name}${so} the runtime lib.

I'll stop this round of review here; I haven't took a look at the actual
functionality yet.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄⠀⠀⠀⠀

Reply | Threaded
Open this post in threaded view
|

Bug#925911: RFS: lopsub-1.0.2 [ITP]

Andre Noll
On Sat, Mar 30, 23:58, Adam Borowski wrote

> On Thu, Mar 28, 2019 at 11:41:45AM +0100, Andre Noll wrote:
> >  * Package name    : lopsub
> >    Version         : 1.0.2
>
> Such a version means a native package; only software written specifically
> for Debian which makes no sense outside it should use the native format.
> Even if you're both upstream and the packager, a non-native format is
> helpful in case someone other than you would upload a fix.
>
> This library is certainly not something for Debian only, thus please append
> "-1" to the version, and set debian/source/format to "3.0 (quilt)" (which,
> despite the name, doesn't require actually using quilt).
Sure, I just wasn't aware of this convention, and that "3.0 (quilt)"
is the right choice for a package like lopsub. One question: With this
change applied, dpkg-buildpackage wants the upstream tarball in the
parent directory. I guess I'm supposed to run git archive here to
create it as part of the before-build hook, but I couldn't figure
out where this hook is defined.

> >    Upstream Author : Andre Noll <[hidden email]>
> >  * URL             : http://people.tuebingen.mpg.de/maan/lopsub/
> >  * License         : (L)GPLv3
>
> It would be nice to mention more prominently what parts are GPLv3-ed and
> which are LGPLv3-ed.

The library is LGPLv3 while the lopsubgen executable is GPLv3. The
source code generated by lopsubgen is licensed with a simple
all-permissive license. See lopsub.7 for more information. I've
changed debian/copyright to make this distinction stand out a bit more.

> I'd recommend running "lintian -i" which gives a long descriptive message
> for every warning, including hints how to fix.

Point. This was a very helpful hint indeed. With the long descriptions,
it was easy to squash the remaining few warnings.

> I see a static library installed by the package.  Those shouldn't generally
> be used unless you're doing something special -- static linking makes
> security and bugfix updates extremely tedious.  Libraries should also be
> split into separate binary packages, with lib${name}dev providing
> development files while lib${name}${so} the runtime lib.

Yes, I had this concern as well. I'll change the build system to
create a shared library instead and split the binary package as you
suggest. I'll follow up with another reply when it's ready.

Thanks a bunch for the review
Andre
--
Max Planck Institute for Developmental Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#925911: RFS: lopsub-1.0.2 [ITP]

Adam Borowski-3
On Mon, Apr 01, 2019 at 12:57:51AM +0200, Andre Noll wrote:
> On Sat, Mar 30, 23:58, Adam Borowski wrote
> > On Thu, Mar 28, 2019 at 11:41:45AM +0100, Andre Noll wrote:
> > >  * Package name    : lopsub
> > >    Version         : 1.0.2

> > This library is certainly not something for Debian only, thus please append
> > "-1" to the version, and set debian/source/format to "3.0 (quilt)" (which,
> > despite the name, doesn't require actually using quilt).
>
> Sure, I just wasn't aware of this convention, and that "3.0 (quilt)"
> is the right choice for a package like lopsub. One question: With this
> change applied, dpkg-buildpackage wants the upstream tarball in the
> parent directory. I guess I'm supposed to run git archive here to
> create it as part of the before-build hook, but I couldn't figure
> out where this hook is defined.

There are many workflows for this, but my personal favourite is to skip any
such wrappers and rely on uscan (ie, debian/watch) only.  As most project
will want a watch file anyway, this reduces the amount of work.

Alas, the vast majority of projects use a git host that does provide tarballs
for a tag, thus I have never used uscan with mode=git (as downloading a
tarball is still more likely to produce a reproducible result), and thus
can't give you ready copypasta to use.

> > I see a static library installed by the package.  Those shouldn't generally
> > be used unless you're doing something special -- static linking makes
> > security and bugfix updates extremely tedious.  Libraries should also be
> > split into separate binary packages, with lib${name}dev providing
> > development files while lib${name}${so} the runtime lib.
>
> Yes, I had this concern as well. I'll change the build system to
> create a shared library instead and split the binary package as you
> suggest. I'll follow up with another reply when it's ready.

Sounds good.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄⠀⠀⠀⠀

Reply | Threaded
Open this post in threaded view
|

Bug#925911: RFS: lopsub-1.0.2 [ITP]

Andre Noll
In reply to this post by Andre Noll
On Mon, Apr 01, 00:57, Andre Noll wrote

> > I see a static library installed by the package.  Those shouldn't generally
> > be used unless you're doing something special -- static linking makes
> > security and bugfix updates extremely tedious.  Libraries should also be
> > split into separate binary packages, with lib${name}dev providing
> > development files while lib${name}${so} the runtime lib.
>
> Yes, I had this concern as well. I'll change the build system to
> create a shared library instead and split the binary package as you
> suggest. I'll follow up with another reply when it's ready.

Meanwhile I've addressed these two issues and fixed the remaining
lintian warnings. Please have a look at the current "pu" branch of
the lopsub repo (pu: proposed updates). This branch merges the various
topic branches, notably the branch which adds the debian/ directory and
the branch which adds support for shared libraries. dpkg-buildpackage
now builds two binary packages called liblopsub1 and liblopsub1-dev.

To create the .deb files, run something like

        git clone git://git.tuebingen.mpg.de/lopsub.git
        cd lopsub
        git checkout origin/pu
        git archive --prefix liblopsub1-1.0.2/ @ | xz > ../liblopsub1_1.0.2.orig.tar.xz
        dpkg-buildpackage

This should work on debian-9 and debian-10. I've checked that the
two packages can be installed with dpkg -i and that all projects of
mine which depend on lopsub compile and work as before. ldd shows
that the resulting executables are now linked against the dynamic
library rather than the static one (which still gets installed as
part of the -dev package).

If there are further issues, just let me know.

Thanks
Andre
--
Max Planck Institute for Developmental Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#925911: RFS: lopsub-1.0.2 [ITP]

Andre Noll
On Sat, Apr 06, 21:52, Andre Noll wrote

> On Mon, Apr 01, 00:57, Andre Noll wrote
>
> > > I see a static library installed by the package.  Those shouldn't generally
> > > be used unless you're doing something special -- static linking makes
> > > security and bugfix updates extremely tedious.  Libraries should also be
> > > split into separate binary packages, with lib${name}dev providing
> > > development files while lib${name}${so} the runtime lib.
> >
> > Yes, I had this concern as well. I'll change the build system to
> > create a shared library instead and split the binary package as you
> > suggest. I'll follow up with another reply when it's ready.
>
> Meanwhile I've addressed these two issues and fixed the remaining
> lintian warnings. Please have a look at the current "pu" branch of
> the lopsub repo (pu: proposed updates). This branch merges the various
> topic branches, notably the branch which adds the debian/ directory and
> the branch which adds support for shared libraries. dpkg-buildpackage
> now builds two binary packages called liblopsub1 and liblopsub1-dev.
>
> To create the .deb files, run something like
>
> git clone git://git.tuebingen.mpg.de/lopsub.git
> cd lopsub
> git checkout origin/pu
> git archive --prefix liblopsub1-1.0.2/ @ | xz > ../liblopsub1_1.0.2.orig.tar.xz
> dpkg-buildpackage
>
> This should work on debian-9 and debian-10. I've checked that the
> two packages can be installed with dpkg -i and that all projects of
> mine which depend on lopsub compile and work as before. ldd shows
> that the resulting executables are now linked against the dynamic
> library rather than the static one (which still gets installed as
> part of the -dev package).
>
> If there are further issues, just let me know.
Ping
Andre
--
Max Planck Institute for Developmental Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#925911: RFS: lopsub-1.0.2 [ITP]

Adam Borowski-3
In reply to this post by Andre Noll
(Sorry for slow response time.)

On Sat, Apr 06, 2019 at 09:52:53PM +0200, Andre Noll wrote:
> > > I see a static library installed by the package.  Those shouldn't generally
> > > be used unless you're doing something special -- static linking makes
> > > security and bugfix updates extremely tedious.  Libraries should also be
> > > split into separate binary packages, with lib${name}dev providing
> > > development files while lib${name}${so} the runtime lib.

I'm afraid that the shared library doesn't work: liblopsub1 in /usr/lib
has nothing but an infinite symlink loop from liblopsub.so.unnamed_version
back to itself.

Besides a proper soname, the file should also go to a multiarch dir (ie,
/usr/lib/x86_64-linux-gnu on amd64, /usr/lib/aarch64-linux-gnu on arm64,
etc -- most build systems get it right without your action).

Also, I wonder why you include the soname in the -dev package's name.
That's allowed but usually not what you want -- an ABI break will also
require changing every depending package instead of a simple recompile.
Unless you change the API every time there's a soname bump, it'd be
better to have the -dev package be unversioned.  But this is up to you.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄⠀⠀⠀⠀

Reply | Threaded
Open this post in threaded view
|

Bug#925911: RFS: lopsub-1.0.2 [ITP]

Andre Noll
On Sun, Apr 14, 15:41, Adam Borowski wrote

> On Sat, Apr 06, 2019 at 09:52:53PM +0200, Andre Noll wrote:
> > > > I see a static library installed by the package.  Those shouldn't generally
> > > > be used unless you're doing something special -- static linking makes
> > > > security and bugfix updates extremely tedious.  Libraries should also be
> > > > split into separate binary packages, with lib${name}dev providing
> > > > development files while lib${name}${so} the runtime lib.
>
> I'm afraid that the shared library doesn't work: liblopsub1 in /usr/lib
> has nothing but an infinite symlink loop from liblopsub.so.unnamed_version
> back to itself.
It worked when compiling from git, but the generated source tarball
was broken because the version.gen.sh script relied on git. This has
been fixed now.

> Besides a proper soname, the file should also go to a multiarch dir (ie,
> /usr/lib/x86_64-linux-gnu on amd64, /usr/lib/aarch64-linux-gnu on arm64,
> etc -- most build systems get it right without your action).

Done.

> Also, I wonder why you include the soname in the -dev package's name.
> That's allowed but usually not what you want -- an ABI break will also
> require changing every depending package instead of a simple recompile.
> Unless you change the API every time there's a soname bump, it'd be
> better to have the -dev package be unversioned.  But this is up to you.

That's just because I misread section 8.1 of the Debian Policy Manual.
I've renamed the -dev package to liblopsub-dev.

Please find the updated repository at the usual location. As before,
you have to check out the "pu" branch:

        git clone git://git.tuebingen.mpg.de/lopsub.git
        cd lopsub
        git checkout origin/pu
        git archive --prefix liblopsub1-1.0.2/ @ | xz > ../liblopsub1_1.0.2.orig.tar.xz
        dpkg-buildpackage

If there are further issues, just let me know.

Thanks
Andre
--
Max Planck Institute for Developmental Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#925911: RFS: lopsub-1.0.2 [ITP]

Adam Borowski-3
On Sun, Apr 21, 2019 at 05:11:05PM +0200, Andre Noll wrote:
> That's just because I misread section 8.1 of the Debian Policy Manual.
> I've renamed the -dev package to liblopsub-dev.

Not sure if you'd want the _source_ package to have a simple soname-less
name as well; I would but that's up to you -- that'd be nicer and make
having only-one-version transitions easier; on the other hand a
soname-encoded source name is better when there's a need for multiple
coinstallable versions.

Your choice; current state is ok.

> If there are further issues, just let me know.

Just cosmetic stuff:

* installation instructions don't really belong in the man page -- if you
  can read it, you've already managed to install the package.

* please copy the description for liblopsub1 to liblopsub-dev; it currently
  says just "This package contains the development environment for the
  lopsub library."  It's pointless to require the user to check the other
  package -- other libraries alter merely the last part.  Also, it's -dev
  what users pull by hand.

* is there a reason for shipping the static library?  Static linking is
  frowned upon in a distribution -- whenever the library gets updated,
  every reverse dependency has to be recompiled; this is especially nasty
  for security updates.

* (bonus) The nicely documented process for building the example looks
  like something that could be turned into an autopkgtest.  Unlike
  build-time tests, autopkgtests are run against installed packages,
  the way an user would.  That's of course extra effort, by no means
  required -- but, extra testing is always good.

But in general, the package already seems to be in a releasable state.
Could you please change "UNRELEASED" to "unstable" so it can be uploaded?


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄⠀⠀⠀⠀

Reply | Threaded
Open this post in threaded view
|

Bug#925911: RFS: lopsub-1.0.2 [ITP]

Andre Noll
On Sun, Apr 21, 22:25, Adam Borowski wrote
> On Sun, Apr 21, 2019 at 05:11:05PM +0200, Andre Noll wrote:
> > That's just because I misread section 8.1 of the Debian Policy Manual.
> > I've renamed the -dev package to liblopsub-dev.
>
> Not sure if you'd want the _source_ package to have a simple soname-less
> name as well; I would but that's up to you -- that'd be nicer and make
> having only-one-version transitions easier; on the other hand a
> soname-encoded source name is better when there's a need for multiple
> coinstallable versions.

There are no plans for multiple incompatible versions. Instead, the
plan is to keep the ABI compatible forever, using symbol versioning
if necessary. Therefore I've changed the name of the source package
from liblopsub1 to liblopsub.

> * installation instructions don't really belong in the man page -- if you
>   can read it, you've already managed to install the package.

Right. OTOH, the instructions might be helpful for the web page, which
is just the html version of lopsub.7. I've moved the instructions to
the README file, and adjusted lopsub.7 slightly.

> * please copy the description for liblopsub1 to liblopsub-dev; it currently
>   says just "This package contains the development environment for the
>   lopsub library."  It's pointless to require the user to check the other
>   package -- other libraries alter merely the last part.  Also, it's -dev
>   what users pull by hand.

Done.

> * is there a reason for shipping the static library?  Static linking is
>   frowned upon in a distribution -- whenever the library gets updated,
>   every reverse dependency has to be recompiled; this is especially nasty
>   for security updates.

The main reason I've kept it is that the Debian Policy Manual says

        The static library (libraryname.a) is usually provided in addition
        to the shared version.

But yes, nobody needs the static library, so I've removed it from
the build.

> * (bonus) The nicely documented process for building the example looks
>   like something that could be turned into an autopkgtest.  Unlike
>   build-time tests, autopkgtests are run against installed packages,
>   the way an user would.  That's of course extra effort, by no means
>   required -- but, extra testing is always good.

I guess I need some help here.

        https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html

describes the format of debian/tests/control, but does not say
how to set up the test environment. Since the tests do not need to
run as root, and do not access the network either, a simple chroot
environment should be fine. But how do I set up such an environment
for use with autopkgtest?

> But in general, the package already seems to be in a releasable state.
> Could you please change "UNRELEASED" to "unstable" so it can be uploaded?

Done. Please have a final look. If everything is fine, I can merge
the various topic branches to master (so that master becomes what is
pu now), and tag the result as v1.0.3.

Thanks
Andre
--
Max Planck Institute for Developmental Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#925911: RFS: lopsub-1.0.2 [ITP]

Andre Noll
On Mon, Apr 22, 17:30, Andre Noll wrote
> > But in general, the package already seems to be in a releasable state.
> > Could you please change "UNRELEASED" to "unstable" so it can be uploaded?
>
> Done. Please have a final look. If everything is fine, I can merge
> the various topic branches to master (so that master becomes what is
> pu now), and tag the result as v1.0.3.

Ping
Andre
--
Max Planck Institute for Developmental Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/

signature.asc (201 bytes) Download Attachment