Re: [internal-projects] [Debian-multimedia] Start an official internal project!
>>>>> "rh" == Raphael Hertzog <hertzog@debian.org> writes:
rh> It depends on what rules you're speaking about. Some rules can
rh> change quickly and others can't.
I admit that it's been a long time since I last checked debian rules
and I wandered around in debian-devel, so my impressions are not that
first-handed.
rh> Everything related to the packaging is usually evolving quite
rh> quickly. If you think about rules like DFSG and social
rh> contract, you will have troubles making them evolve ... :-)
You have discovered my secret plans for debian domination at last. :-)
rh> This one is problematic yes. In particular for mplayer in your
rh> case. Suppose that you won't be able to integrate it in
rh> Debian (because ftpmaster refuse to take the risk to add
rh> it). You can still package it and make it available from a
rh> third party site and modify the installation process to ask a
rh> question like this one "some interesting software with
rh> problematic licenses are available on a separate apt
rh> repository, do you want me to add it to your APT configuration
rh> ?"
Say you have a package called
problematic-program-installer
which adds an apt source line and warns the user. In that case is it
feasible for problematic-program-installer to use debian
infrastructure, given that practically the program itself is not part
of debian?
rh> I understand you, I just want to prove you that you can
rh> overcome all your problems within Debian, it's just a matter
rh> of knowing the right thing to do. You can always ask for input
rh> on debian-devel... and a good compromise is likely to be
rh> proposed by someone (after that it's up to the subproject
rh> leader to decide together with the contributors what is the
rh> best compromise).
I like your attitude. I think that will make things much easier for
Marco and Guenter - whose project, I remember more for their benefit
than for mine, is not legally bound by AGNULA or EU funds. We are
working to clear hurdles and try to cooperate as much as possible, but
I stressed that because it would be unfair to them to catalog their
project as anything else but their own.
rh> If you have made many changes to many packages, you still have
rh> the possibilty to change the default configuration of the
rh> reportbug package that you provide ... :-)
That's something I had thought about, and also I thought about
providing a graphical interface for it (a la bug-buddy).
rh> Or better, the heavily modified packages that you provide can
rh> have a file /usr/share/bug/<package>/control which redirect
rh> the bug report to someone else ... please check
rh> /usr/share/doc/reportbug/README.developers
That's really nice, I must admit. [scribble, scribble] wrote on my
TODO to have a look at how reportbug works exactly, that would greatly
help my job in AGNULA.
rh> As you see, there's always the possibility to do *the right
rh> thing*. :-)
As there is always the possibility to *screw it up* I try to take the
most conservative road possible. :)
Thank you again for your answers, you are really helping me.
bye,
andrea
--
Andrea Glorioso andrea.glorioso@centrotemporeale.it
Centro Tempo Reale http://www.centrotemporeale.it/
AGNULA/DeMuDi Technical Manager http://www.[demudi|agnula].org/
"There's no free expression without control on the tools you use"
Reply to: