Bug 314911 - Review Request: tuncfg - Userspace TUN/TAP configuration utility
Review Request: tuncfg - Userspace TUN/TAP configuration utility
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Tom "spot" Callaway
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FE-Legal FE-DEADREVIEW
  Show dependency treegraph
 
Reported: 2007-10-01 20:54 EDT by Lennert Buytenhek
Modified: 2008-01-15 17:06 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-02 16:53:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
tcallawa: fedora‑review-


Attachments (Terms of Use)

  None (edit)
Description Lennert Buytenhek 2007-10-01 20:54:17 EDT
Spec URL: http://www.wantstofly.org/~buytenh/tuncfg/tuncfg.spec
SRPM URL: http://www.wantstofly.org/~buytenh/tuncfg/tuncfg-1.1-1.src.rpm
Description: This package contains a utility for configuring the
Linux TUN/TAP network driver.
Comment 1 Lennert Buytenhek 2007-10-01 20:59:26 EDT
This is my first package.  I am looking for a sponsor.
Comment 2 Chris PeBenito 2007-10-03 13:15:47 EDT
I noticed that the %dist macro isn't being used in the revision, and the package
name doesn't match the upstream (tuncfg vs. tun), please see
http://fedoraproject.org/wiki/Packaging/NamingGuidelines which has info on both
of these points.
Comment 3 Lennert Buytenhek 2007-10-03 22:29:08 EDT
The tun package contains Linux, FreeBSD and Solaris kernel modules, and a
Linux userland configuration utility called 'tuncfg'.  I am not packaging
any of the kernel modules (d'oh), so I have named the package after the
only piece of the upstream tun package that I _am_ packaging, namely 'tuncfg'.

The Release field doesn't contain %{?dist} because tuncfg doesn't depend on
anything, so we can just use the very same binary package for every distro
release.
Comment 4 Tom "spot" Callaway 2007-10-23 09:37:23 EDT
Even if it doesn't depend on anything, you might consider using %{?dist}
anyways, since the code is compiled, and will inevitably require rebuilds for
things like gcc changes. Fedora will still inherit older packages.
Comment 5 Tom "spot" Callaway 2007-10-23 09:54:03 EDT
Also, the tuncfg.c code is not licensed, there is no clear statement of
licensing intent either. Can you contact upstream and have them clarify the
license for tuncfg.c (preferably with a new code release, but an email will
suffice)?
Comment 6 Bishop Clark 2007-10-24 00:12:04 EDT
The clear statement is for GPL2.  That's in the source, but not in tuncfg.c, so
may have been overlooked.  Have the tun people been approached about a package
for fedora?

The specfile, as attached, doesn't use %dist; probably because the %dist crutch
doesn't appear in all distros for which the project may be packaged, and really
assumes a rebuilding user dumb enough to need %builddeps but smart enough to
activate the magic crutch anyway if the specfile can't cope.
Comment 7 Tom "spot" Callaway 2007-10-24 09:21:43 EDT
(In reply to comment #6)
> The clear statement is for GPL2.  That's in the source, but not in tuncfg.c, 
> so may have been overlooked.  

Yes, but there is no clear statement in any attached documentation, the only
reference to the license is for the kernel module, which is not linked to tuncfg
at all. Which is why we need the copyright holder (is that you?) to say that it
is GPL (or preferrably, to re-release the source with the header license
attribution included in tuncfg.c).

> The specfile, as attached, doesn't use %dist; probably because the %dist crutch
> doesn't appear in all distros for which the project may be packaged, and really
> assumes a rebuilding user dumb enough to need %builddeps but smart enough to
> activate the magic crutch anyway if the specfile can't cope.

You really don't understand what we're doing here, sir. ;)

%{?dist} will be undefined on distros/environments where it does not appear/is
not defined, and thus, will not affect anything.

In this specific package, %{?dist} isn't being used to conditionalize anything
(and even if it was, our guidelines specifically require its use in such a way
that it will not error out if it is unset). I'm recommending its use so that the
packager doesn't accidentally end up with two packages with the same N-V-R in
two different branches.

Please take a moment and read: http://fedoraproject.org/wiki/Packaging/DistTag
Comment 8 Tom "spot" Callaway 2008-01-02 16:53:51 EST
I'm closing this bug out. Without the license clarification, we cannot ship this
package as is. Feel free to reopen if the licensing problems are resolved.

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