Re: pkgsrc: wip/{audacious,audacious-plugins}

I've dealt with this issue a number of times.  Some general
considerations:

1) If upstream asks that something not be packaged, it's usually a good
idea to respect their wishes.  There's no legal obligation to do so,
assuming it's free software (the web page does not immediately make this
clear), but it's important in maintaining a sense of community within
the free software world.

2) First, the stable version should be packaged.  This assumes that the
advice from upstream that most users should run the stable version is
reasonable, and most of the time.  pkgsrc is mainly to save people time
over having to do builds themselves as well as having to figure out
which version to use if they are a casual user.

3) Then, packaging development versions can be reasonable, and we
generally call them -devel.  So audacious would be 1.3 and
audacious-devel 1.4a4.  The DESCR should note very clearly that this is
an unstable release, and contain any comments from upstream that it's
only for testing, etc.

Usually upstream is much less bothered about -devel packages when their
recommended version is available and (implicitly) labeled as such.

A good example is gimp and gimp24.

A comment for upstream:

Please consider using version numbers, even for 'dr' series, that sort
properly.  The odd/even numbering scheme used by gimp etc. works well,
as does the old FSF scheme of calling 1.4dr4 "1.3.84".  It seems that
many projects are making up their own naming schemes, and supporting
this in packaging systems requires custom code for each one.

Comments the packaging:

PKGNAME should be munged to somehow use the dr4, so that a later package
will have a higher version.  It seems that dr is even before alpha, so
that's may a "don't package" hint.  So maybe call it 1.4a0.4 so that the
first alpha will be greater.

audacity and audacity-plugins both are 1.4dr4, so there should be a
Makefile.common in audacity that sets all of that stuff.

You probably should set PKG_SUGGESTED_OPTIONS.

In an ideal world each plugin would be a separate package, using a
Makefile.plugins for most of the work.

DESCR should describe what audacious does first, and then explain the
forking issue.  It is good to describe the history so that people
looking at both packages can choose what they want.

It's unclear if there are any codec licensing issues.  The general trend
is to make all those (in a free player) optional and default to not
including them.  This is ugly, and having them be plugins is best
because then the base package can be the same, and not have
LICENSE/RESTRICTED, and then each plugin has it's own trouble.  This
works with binary packages, whereas options are messy.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/