[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [internal-projects] [Debian-multimedia] Start an official internal project!



Le Fri, Feb 14, 2003 at 12:24:29PM -0400, andrea.glorioso@centrotemporeale.it écrivait:
> Agreed.   Anyway, as I  understood Debian structures from my readings,
> an official  change in  Debian rules (*if*   we wanted to push  such a
> change,  something   that  in   my  opinion  is  both   difficult  and
> undesiderable)  is not something that can  cope with  the schedules we
> have to face.

It depends on what rules you're speaking about. Some rules can change
quickly and others can't.

Everything related to the packaging is usually evolving quite quickly.
If you think about rules like DFSG and social contract, you will have
troubles making them evolve ... :-)

> relationships  with other partners in  the  project.  If, for example,
> Debian rules say that  a package is not  ammissible but other partners
> say it is and push for this package to be a part of DeMuDi, it makes a

This one is problematic yes. In particular for mplayer in your case.
Suppose that you won't be able to integrate it in Debian (because
ftpmaster refuse to take the risk to add it). You can still package it
and make it available from a third party site and modify the
installation process to ask a question like this one "some interesting
software with problematic licenses are available on a separate apt
repository, do you want me to add it to your APT configuration ?"

That's it, you managed to avoid the problem and everyone is happy. It's
much like non-free ... non-free is not part of Debian but we give the
choice to the user anyway.

> Debian.    This is   simply an example,    although I   think  it's an
> appropriate one.  And  it's not even said that  such an  example would
> ever happen, but both because  of my personal  attitude and because  I
> have a  binding contract with Tempo  Reale (and consequently  with the
> EU) I wish to avoid  any possible problem  that could arise as much as
> possible.

I understand you, I just want to prove you that you can overcome all
your problems within Debian, it's just a matter of knowing the right
thing to do. You can always ask for input on debian-devel... and a good
compromise is likely to be proposed by someone (after that it's up to
the subproject leader to decide together with the contributors what is
the best compromise).

> Would this be feasible?  My worst fear  is that developers get reports

Yes it would, provided that you follow some good logic : if you're only
recompiling the official Debian package then any bug reported on your
recompiled is probably also in the other version. This does also mean
that you shouldn't let your recompiled version get too much out of date
otherwise you'll be missing some fixes applied to the other version.
To avoid too much headache, you should probably just use the package
in testing, they are new enough and don't change to often. Of course,
the package to use depends on the progress of the integration of any
patches that you submitted to the maintainer ...

> coming from DeMuDi and react badly to the submitter.  From their point
> of view, they are  quite right, because the  package is not part of an
> official Debian       distribution  (be it   sid,   sarge,    woody or
> loolapalooza).  From my point of view, that would a pity for DeMuDi.

If you have made many changes to many packages, you still have the
possibilty to change the default configuration of the reportbug
package that you provide ... :-)

Or better, the heavily modified packages that you provide can have
a file /usr/share/bug/<package>/control which redirect the bug report to
someone else ... please check /usr/share/doc/reportbug/README.developers

As you see, there's always the possibility to do *the right thing*. :-)

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com



Reply to: