ffmpeg status?

[Loïc Minier]

On Mon, Jun 16, 2008, Reinhard Tartler wrote:
> In what way did we apply 'Debian standards' to the package? In the past
> we had a huge pile of patches not forwarded upstream, and nowadays we
> make large parts of the software unusable. I don't really agree that
> this is 'debian standard', at least it shouldn't be.

 This is the Debian tree of ffmpeg because Debian requires to strip some
 things of; is this clearer?  By Debian standards, I don't necessarily
 mean "policy", I do mean all requirements such as the ones from
 ftpmasters etc.

> Or the other way round: the name would in some ways 'endorse' crippling
> the package. This is something that is very difficult to communicate to
> upstream, since they have a very different opinion to our ftpmaster team
> on the patents matter. I had to invest quite some amount of energy to
> convince e.g. Diego that I don't endorse this way of handling the
> package at all, but that's still our best option we have. So we agreed
> that naming it '-restricted' was to most honest way to go.

 ffmpeg-restricted reminds me too much of the Ubuntu restricted
 component; I don't think the rules of the restricted component of
 Ubuntu are the rationale for this name, so we'd better avoid it (you
 wouldn't want a ffmpeg-restricted in Ubuntu main or Ubuntu universe).

 I'm personally not in favor of renaming source packages which are
 pulled from upstream project when we repack them, but I understand why
 some people want to do this.  The usual names are often +dfsg, +repack,
 or something similar, but in the end there are fundamentally two
 approaches for the addition of a suffix:
 a) expressing that you changed the tree
 b) listing stuff which you changed

 a) is basically saying "this is not the original upstream source";
 typically +repack, +dfsg, etc. match this case

 b) is what we tried doing (IMO not very successfully) with ffmpeg:
 ffmpeg-free, ffmpeg-non-free, ffmpeg-some-free-some-not-quite-so;
 nowadays it becomes clearer that it's more something like
 ffmpeg-noenforced-patents, but what if the rules change?  I don't want
 source package names to be renamed over and over...

 So instead of following b) which might be a moving definition, let us
 just name the Debian ffmpeg tree ... ffmpeg-debian; I don't think it
 can be clearer and it holds true even if the definition of what's
 acceptable in Debian changes for the better or the worse.

 Heck, what about the stuff which we will change or add in the future
 which isn't related to patents at all?  This would also be considered
 as Debian changes.

-- 
Loïc Minier