Bug 314911

Summary: Review Request: tuncfg - Userspace TUN/TAP configuration utility
Product: [Fedora] Fedora Reporter: Lennert Buytenhek <buytenh>
Component: Package ReviewAssignee: Tom "spot" Callaway <tcallawa>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: fedora-package-review, notting
Target Milestone: ---Flags: tcallawa: fedora‑review-
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
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:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 182235, 201449    

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.