On 09/02/2011 12:25, Stefane Fermigier wrote: >> My "apt-get source, hack and dpkg-bp" was seen from a derivative >> developer or sysadmin that has to modify the way a software works >> on its own system or distribution. > > As a sysadmin, I've never found the need to repackage a package. > > If I need to configure a system, I will edit some files in /etc. > > If I need to be more rigorous about it, I will but /etc under git > control. > > If I need to administer many servers this way, I will use tentakel or > chef or puppet. This just takes into account the modification for which /etc is enough. There are plenty of other reasons to modify a package: if you're administering the computers of a scientific research institute, you may be interested in rebuilding your libraries for the platform you're using, to have best performances. You may need to have different compilation flags on a library. You may want to use a patched version of some program. The other case is when you're a derivative distribution developer: than you may want to change something in each package. > I'm insisting on the fact that: > > 1. there is room for interpretation in the so called "policies", for > instance, that there "should only be one instance of tomcat" in the > distribution. There's room for interpretation in the things the policy isn't clear about: but our policy is very clear that Debian doesn't like embedded code copies and that all code has to build from sources. > 2. sometimes the policies need to be changed in the face of reality. > Otherwise, we end up like these poor monkeys: > > http://freekvermeulen.blogspot.com/2008/08/monkey-story-experiment-involved-5.html Well, I don't think this story is appropriate here: I'm not defending the policy because it's the policy; I'm defending it because I think it tells how to do things in the saner way I'm able to think of (embedded copies and sourceless builds, in this case; did I miss anything?). Anyway, as has already been said, changing the policy is a big thing: you can try to convince us why it would be a good thing (and, in my case, you're failing; don't know about other DDs), but then the change has to pass through much harder discussions. >> What is not true? The fact that packaging things in Debian is >> difficult or the fact that it's so because it requires some added >> value? > > No, the fact that it *only* requires "some" added value. > > You are requiring *much more*. You are requiring upstream developers > to *completely change* their development process, dropping maven to > use some non-existing tool, renouncing their QA process, etc. I think this mainly depends on the fact that these projects are using a development model which has many problems: the main one is the fact that they decide to support the compilation against only a specific version of each library. In my opinion, this is a bad thing: libraries should been stable enough not to have these problems; bugfix releases shouldn't do other than fix bugs, shouldn't introduce new depencies; minor releases should ensure backward compatibility nevertheless. >> Of course, we could disagree on whether modifying a package to >> conform with Debian policy is an added value or not: > > Modifying a package in a way that introduces significant variance > (I'm not talking about tweaking the startup scripts to conform to the > FHS, or adding an administrative panel, etc. I'm talking about > changing a jar) *reduces* the value of a package, because it's not > anymore the certified version (the one that has been through the > extensive QA process). > >> If you agree to have your software in Debian under these >> conditions, then we're happy to host it, of course. If you think >> that it's going to take too much time, I can't blame you. > > It's not about "too much time". It's about asking upstream developers > to *completely change* the way they are working, *completely > reinventing* a whole family of build tools and processes that don't > exist yet. But that are, in my opinion, saner than those they're using now. Anyway, I would like to hear other voices on this point. > As a Debian / Ubuntu user, this time, I'm really pissed off that such > packages are not available, and that I, or other members of my team, > have to install and configure these packages by hand instead of using > apt-get. I already discussed it: I'm sorry too that some big software isn't available, but it is in Debian's DNA sticking very seriously to its policy, because we think that it's what many our users appreciate. I know that trading such a hard commitment for renouncing to some big software is not an easy deal, but that's the way that we decided to do it. If you have different needs and priorities, that's fair: but your solution isn't trying to make Debian like you want (because Debian has a huge inertia given by all the people that like it as it's now); instead, you should look out to understand if some other distribution is better for you. This is valid for you (as a user) like for every other user. Moreover, I'm not saying that Debian doesn't want to package your software; I'm just saying that we don't seem to have enough manpower to do it. This may change in the future. In the meantime, the solution proposed by Torsten could address some of the problems; certainly, it wouldn't reduce the manpower needed. > I'm also fed up with private apt repositories that only work with an > obsolete version of Debian (or Ubuntu). Well, here the key is to keep that repository up-to-date. If you're managing it, it's definitely you're responsibility. :-) > BTW, here's what geogebra's download page > (http://www.geogebra.org/cms/en/download) says: "You are free to > copy, distribute and transmit GeoGebra for non-commercial purposes". > > Isn't this a flagrant violation of the DFSG (Item 6, "No > Discrimination Against Fields of Endeavor") ? Wasn't the first thing I said about geogebra that I was proud to have made it free software, while before it wasn't? Giovanni. -- Giovanni Mascellani <mascellani@poisson.phc.unipi.it> Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascellani@jabber.org / giovanni@elabor.homelinux.org
Attachment:
signature.asc
Description: OpenPGP digital signature