Bug 970956 - Review Request: clens - A convenience library to aid in porting code from OpenBSD
Review Request: clens - A convenience library to aid in porting code from Ope...
Status: NEW
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
:
: 1036299 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-05 06:04 EDT by Christopher Meng
Modified: 2014-06-22 13:33 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Christopher Meng 2013-06-05 06:04:50 EDT
Spec URL: http://cicku.me/libclens.spec
SRPM URL: http://cicku.me/libclens-0.7.0-1.fc20.src.rpm
Description: clens is a convenience library to aid in porting code from OpenBSD to different
operating systems. Operating systems traditionally have different enough APIs
that porting code is painful and can litter pretty code with ugly ifdef goo.
In order to keep code readable and drastically reduce the number of ifdefs
needed, clens brings other APIs or missing functions into specific OS "focus".
Fedora Account System Username: cicku
Comment 1 Björn "besser82" Esser 2013-06-05 13:47:35 EDT
There's only a static lib generated during %build, which isn't packaged at all. Please get in touch with upstream to have it build a shlib and I'll take another run.
Comment 2 Christopher Meng 2013-06-13 05:48:17 EDT
(In reply to Björn Esser from comment #1)
> There's only a static lib generated during %build, which isn't packaged at
> all. Please get in touch with upstream to have it build a shlib and I'll
> take another run.

Hi, quoted from upstream:

Clens is not intended to be a shared library. There is a library that already provides some BSD compatibility functions (libbsd) which clens does not endeavor to imitate. After discussing this with the other folks, we've decided to keep it static only. We do understand the implications of this and think it is quite unfortunate that Fedora policy doesn't provide support for static libraries, but not everything should be a shared library.

So I want to make this package like a -devel like pacakge, only ontains headers.

Is it OK?
Comment 3 Michael Schwendt 2013-06-13 06:26:04 EDT
There's a hint in comment 1:

| There's only a static lib generated during %build,
| which isn't packaged at all.

You cannot simply delete the compiled/built library in %install. You need to package it in accordance with https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries
Comment 4 Björn "besser82" Esser 2013-06-13 06:48:59 EDT
(In reply to Michael Schwendt from comment #3)
> There's a hint in comment 1:
> 
> | There's only a static lib generated during %build,
> | which isn't packaged at all.
> 
> You cannot simply delete the compiled/built library in %install. You need to
> package it in accordance with
> https://fedoraproject.org/wiki/Packaging:
> Guidelines#Packaging_Static_Libraries

The other way would be patching Makefile(.am) to build a shlib instead, regenerate with `autoreconf -vfi` (if applicable) and package it that way.  Just having headers is usually (best known exception is boost-base, but it's specially designed this way) not enough in C/C++.  There need to be binary-libs to link against.

Just packaging the static lib is not such a good approach, since on main goal in development of Fedora is to get rid of them. The other problem I see is, if someone ports a daemon-app from bsd to Fedora using libclens-static, usefully hardening this is close to impossible. Linking against static libs doesn't allow PIE and RELRO with immeditate binding.

The next question comming into my mind:
What does libclens provide additionally to libbsd?  Is it really worth the affort?
Comment 5 Christopher Meng 2013-06-13 07:46:18 EDT
In fact this package is a base of assl:

https://opensource.conformal.com/wiki/Agglomerated_SSL
Comment 6 Christopher Meng 2013-07-31 04:04:56 EDT
Hi Bjorn, what should I do now?
Can I only package headers?
Comment 7 Christopher Meng 2013-10-25 04:20:03 EDT
Hi all, before update this review, I want to know which name is better? clens(tarball name) or libclens(more like a library)?
Comment 8 Mario Blättermann 2013-10-27 12:51:39 EDT
(In reply to Christopher Meng from comment #6)
> Hi Bjorn, what should I do now?
> Can I only package headers?

I'm not sure, but there was an attempt to do so:
https://bugzilla.redhat.com/show_bug.cgi?id=865116
Unfortunately, the review was never completed, because there was no need anymore for it as a dependency for another package.

(In reply to Christopher Meng from comment #7)
> Hi all, before update this review, I want to know which name is better?
> clens(tarball name) or libclens(more like a library)?

There's no unique guideline for, just that:
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#General_Naming
You might use the tarball name, but to see directly that it is a library, you might use the "lib" prefix. It is your choice.
Comment 9 Michael Schwendt 2013-10-28 06:22:41 EDT
We don't apply a "lib" prefix to libraries. We prefer the "upstream tarball or project name", which often means the src.rpm %name matches the tarball name.

  rpm -qf /usr/lib*/lib*.so*|grep -v ^lib|sort|uniq

Sometimes, depending on what components a software project builds, it can make sense to build a -libs subpackage. In other cases, the project may include programs, and then the added "lib" prefix would be a hindrance (and it would be necessary to redefine the binary rpm names completely to be closer to the upstream name).
Comment 10 Christopher Meng 2013-11-30 12:33:51 EST
*** Bug 1036299 has been marked as a duplicate of this bug. ***
Comment 11 Christopher Meng 2013-12-02 00:14:01 EST
Mark, I will push a new spec based on yours. You're welcome to comaintain it(Or let me comaintain it)

Thanks.

Will you want to review it? ;)
Comment 12 Mark McKinstry 2014-01-07 20:51:15 EST
Hi Christopher,

Your spec doesn't differ that much from mine so feel free to use whichever you'd prefer. Lemme know what the URL are for the spec and src.rpm and I'd be happy to review it.

I dunno how I managed to miss this bug report when I tried to see if there was an existing review for clens, I think I searched for 'clens' instead of '*clens*' .
Comment 13 Christopher Meng 2014-01-10 05:35:48 EST
(In reply to Mark McKinstry from comment #12)
> Hi Christopher,
> 
> Your spec doesn't differ that much from mine so feel free to use whichever
> you'd prefer. Lemme know what the URL are for the spec and src.rpm and I'd
> be happy to review it.
> 
> I dunno how I managed to miss this bug report when I tried to see if there
> was an existing review for clens, I think I searched for 'clens' instead of
> '*clens*' .

Fine, wait a few days.
Comment 14 Christopher Meng 2014-01-12 08:41:47 EST
Mark, I'd like to know some details of this software with mg, can you provide some information?

Thanks.
Comment 15 Mark McKinstry 2014-01-15 21:54:23 EST
Christopher,

Here's the spec for the one I built using clens: http://mmckinst.fedorapeople.org/packages/mg/mg.spec

Is this what you're looking for?

The author has some background info at http://homepage.boetes.org/software/mg/README_PORTING FWIW.
Comment 16 Christopher Meng 2014-01-15 22:42:00 EST
Hm.. explains a bit.

I asked this because I don't want to ship static lib in the package, only headers are preserved. And I don't want to hack it and make it become a shared lib also.

Looking forwards to your opinion again.
Comment 17 Michael Schwendt 2014-01-16 03:58:28 EST
> I asked this because I don't want to ship static lib in the package,
> only headers are preserved. And I don't want to hack it and make it
> become a shared lib also.

See comment 3.

Perhaps you could make clear what you are trying to do? You must not delete the library (containing all of or most of the implementation) when the software consists of headers *and* a library.
Comment 18 Christopher Meng 2014-04-26 22:25:48 EDT
Mark, I've updated the spec, please have a look and see if it works, hope you can review it.

SPEC URL: http://misc.cicku.me/fedora/clens.spec
SRPM URL: http://misc.cicku.me/fedora/clens-0.7.0-1.fc21.src.rpm
Comment 19 Pavel Alexeev 2014-05-05 04:46:22 EDT
1) For what that trick:
cat << EOF > configure
#!/bin/bash
EOF
chmod +x configure
%configure
?

Just drop that lines - it looks like a garbage.

2) Some files under BSD (2 or 3 clause) and some under ISC. Why you set ISC as license field for package? I think it should be BSD and ISC.
3) Shouldn't be it called libclens instead clens?
4) Honestly I've first time review static library. Be aware what according to guideline https://fedoraproject.org/wiki/Packaging:Guidelines#Statically_Linking_Executables you must need citing "The packager must provide rationale for linking statically, including precedences where available, to FESCO for approval."
So, as it packaged as dependency to mg (bz#1010897) i strongly encourage you firstly request that exception to do not make useless effort.
Comment 20 Christopher Meng 2014-05-05 04:53:40 EDT
(In reply to Pavel Alexeev (aka Pahan-Hubbitus) from comment #19)
> 1) For what that trick:
> cat << EOF > configure
> #!/bin/bash
> EOF
> chmod +x configure
> %configure
> ?
> 
> Just drop that lines - it looks like a garbage.

I used to agree with you... But I need to set the building flags properly.

> 2) Some files under BSD (2 or 3 clause) and some under ISC. Why you set ISC
> as license field for package? I think it should be BSD and ISC.

Please paste the license check results if possible, this package is ISC licensed described in README.md.

> 3) Shouldn't be it called libclens instead clens?

No, I insist on naming it based on the tarball name.

> 4) Honestly I've first time review static library. Be aware what according
> to guideline
> https://fedoraproject.org/wiki/Packaging:
> Guidelines#Statically_Linking_Executables you must need citing "The packager
> must provide rationale for linking statically, including precedences where
> available, to FESCO for approval."
> So, as it packaged as dependency to mg (bz#1010897) i strongly encourage you
> firstly request that exception to do not make useless effort.

That's for "Statically Linking Executables", means those linked with static libraries, but not static libraries itself.
Comment 21 Pavel Alexeev 2014-05-05 05:02:54 EDT
(In reply to Christopher Meng from comment #20)
> (In reply to Pavel Alexeev (aka Pahan-Hubbitus) from comment #19)
> > 1) For what that trick:
> > cat << EOF > configure
> > #!/bin/bash
> > EOF
> > chmod +x configure
> > %configure
> > ?
> > 
> > Just drop that lines - it looks like a garbage.
> 
> I used to agree with you... But I need to set the building flags properly.

Sure.
You may just export those env variables like:
  CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; 
  CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; 
  LDFLAGS="${LDFLAGS:-%__global_ldflags}"; export LDFLAGS;

Meantime it only c language, so:
make %{?_smp_mflags} CFLAGS="${CFLAGS:-%optflags}" LDFLAGS="${LDFLAGS:-%__global_ldflags}"
should be full enough.

> > 2) Some files under BSD (2 or 3 clause) and some under ISC. Why you set ISC
> > as license field for package? I think it should be BSD and ISC.
> 
> Please paste the license check results if possible, this package is ISC
> licensed described in README.md.


BSD (2 clause)
--------------
clens-0.7.0/include/clens/sys/tree.h

BSD (3 clause)
--------------
clens-0.7.0/include/clens/glob.h
clens-0.7.0/include/clens/sys/queue.h

BSD (3 clause) ISC
------------------
clens-0.7.0/src/fgetln.c
clens-0.7.0/src/fmt_scaled.c
clens-0.7.0/src/glob.c

BSD (4 clause) ISC
------------------
clens-0.7.0/src/fparseln.c

ISC
---
clens-0.7.0/config/freebsd/build-pkg.sh
clens-0.7.0/config/prep_release.sh
clens-0.7.0/include/clens/clens.h
clens-0.7.0/include/clens/readpassphrase.h
clens-0.7.0/src/arc4random_buf.c
clens-0.7.0/src/arc4random_uniform.c
clens-0.7.0/src/clens.c
clens-0.7.0/src/strlcat.c
clens-0.7.0/src/strlcpy.c
clens-0.7.0/src/strtonum.c
clens-0.7.0/version.sh

Unknown or generated
--------------------
clens-0.7.0/buildver.sh


Is not it available for you??

> > 4) Honestly I've first time review static library. Be aware what according
> > to guideline
> > https://fedoraproject.org/wiki/Packaging:
> > Guidelines#Statically_Linking_Executables you must need citing "The packager
> > must provide rationale for linking statically, including precedences where
> > available, to FESCO for approval."
> > So, as it packaged as dependency to mg (bz#1010897) i strongly encourage you
> > firstly request that exception to do not make useless effort.
> 
> That's for "Statically Linking Executables", means those linked with static
> libraries, but not static libraries itself.

Yes, there I mention mg. It will be intended to be linked with clens statically. You must request it exception from FESCO. Otherwise it have no sense to packaging that static lib.
Comment 22 Michael Schwendt 2014-05-05 06:31:20 EDT
> cat << EOF > configure
> #!/bin/bash
> EOF
> chmod +x configure
> %configure

There have been various forms of that over the years. One other is:

  %configure || :



> You must request it exception from FESCO.

You are misreading the guidelines. What you refer to is the case where a packager wants to link statically when a library is available _both_ as a shared and static build. Then it must be justified why the shared lib is not linked with instead.

On the contrary, for a static-only library this one applies:

https://fedoraproject.org/wiki/Packaging:Guidelines#Programs_which_don.27t_need_to_notify_FESCo
Comment 23 Christopher Meng 2014-05-05 11:21:35 EDT
For the license issue, upstream has replied to me:

https://github.com/conformal/clens/issues/1
Comment 24 Pavel Alexeev 2014-05-05 16:56:22 EDT
(In reply to Michael Schwendt from comment #22) 
> You are misreading the guidelines. What you refer to is the case where a
> packager wants to link statically when a library is available _both_ as a
> shared and static build. Then it must be justified why the shared lib is not
> linked with instead.
> 
> On the contrary, for a static-only library this one applies:
> 
> https://fedoraproject.org/wiki/Packaging:Guidelines#Programs_which_don.
> 27t_need_to_notify_FESCo

Yes, you are right. Sorry.


(In reply to Christopher Meng from comment #23)
> For the license issue, upstream has replied to me:
> 
> https://github.com/conformal/clens/issues/1
Heh. Cool. But are you looked into files?? There different licenses mostly because they borrowed from different projects! For example:

BSD (2 clause)
--------------
clens-0.7.0/include/clens/sys/tree.h
$OpenBSD: tree.h,v 1.13 2011/07/09 00:19:45 pirofti Exp
Copyright 2002 Niels Provos <provos@citi.umich.edu>

BSD (3 clause)
--------------
clens-0.7.0/include/clens/glob.h
clens-0.7.0/include/clens/sys/queue.h

/* $OpenBSD: glob.h,v 1.11 2010/09/24 13:32:55 djm Exp $ */
/* $NetBSD: glob.h,v 1.5 1994/10/26 00:55:56 cgd Exp $ */
/*
 * Copyright (c) 1989, 1993
 * The Regents of the University of California.  All rights reserved.

BSD (3 clause) ISC
------------------
clens-0.7.0/src/fgetln.c
clens-0.7.0/src/fmt_scaled.c
clens-0.7.0/src/glob.c

Copyright (c) 2011 Conformal Systems LLC <info@conformal.com>

and so on.

In no one I have not found Dave Collins as author. So I assume they have not any rights to relicense it.

Bundled issue must be resolved or exceptions requested.

Note You need to log in before you can comment on or make changes to this bug.