Bug 314911

This is my first package.  I am looking for a sponsor.

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.

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.

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.

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)?

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.

(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

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.