----- Forwarded message from William Pitcock <nenolod%atheme.org@localhost>
-----
X-Original-To: jfranz%bsdprojects.net@localhost
From: William Pitcock <nenolod%atheme.org@localhost>
To: Greg Troxel <gdt%ir.bbn.com@localhost>, jfranz%bsdprojects.net@localhost
Subject: Re: pkgsrc: wip/{audacious,audacious-plugins}
Greg Troxel wrote:
> 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.
>
Audacious is indeed free software. Why wouldn't it be? (commentary on how
we could make this more "obvious" would especially be good)
> 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.
>
Yes, this is what I am asking for. :)
> 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.
>
These releases aren't meant to be packaged, so I don't understand the
argument here. The release announcement says "if you want to play with
alpha-quality software, try this, but don't use this in production".
> 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.
>
No, DR releases are the same as alpha. We use the DR name in order to scare
end users away from testing because we're not ready for that. As I said
above, the purpose of these DR releases is only to provide a reference
implementation for third-party authors to update their code to. As
components of the API become finalised, we make a release.
However, stabilization will indeed occur soon, and those will be "beta"
releases followed by some RCs like usual.
> audacity and audacity-plugins both are 1.4dr4, so there should be a
> Makefile.common in audacity that sets all of that stuff.
>
-plugins is seperately maintained once stabilization begins, which is very
soon now.
> 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.
>
I think it is bad to "describe the history", as many people seem to get it
wrong. Mostly the Audacious and BMPx communities interoperate without any
issues, but usually the outsider commentary on "the fork" describes things
incorrectly, causing people to get riled up about it.
Honestly, the only thing which probably should be said about history is
"Audacious is an in-progress rewrite of BMP classic."
> 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.
>
The only codec that is questionable is TTA (the license of the SDK we
include says non-commercial use only). IANAL though, there may be others.
- William
----- End forwarded message -----
--
--
http://users.bsdprojects.net/~jfranz/
Attachment:
pgp4hyTdKILnD.pgp
Description: PGP signature
------------------------------------------------------------------------- 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/
_______________________________________________ pkgsrc-wip-review mailing list pkgsrc-wip-review%lists.sourceforge.net@localhost https://lists.sourceforge.net/lists/listinfo/pkgsrc-wip-review