Hi. On 09/02/2011 10:06, Stefane Fermigier wrote: >> I'd say that this one of the main added value of a distribution: >> many different pieces of software harmonized together, under a >> consistent policy so that people that want to change something in >> the source code and recompile just have to do apt-get source, hack >> the code and dpkg-buildpackage. >> >> Of course I'm not pretending that this is going to satisfy all the >> kind of users: it's just what Debian users are expecting, so it's >> what Debian is offering to its users. > > Maybe I'm an exception, but I've been a Debian user since 1997 or > 1998 (not exclusively, but since that time I have always had from 1 > to 30 Debian or Ubuntu servers to manage), and my home computer is an > Ubuntu. > > I have NEVER used "apt-get source, hack[ed] the code and > dpkg-buildpackage." Not a single time. > > Also, in the context of enterprise applications, you just don't want > to "apt-get source, hack the code and dpkg-buildpackage." You want to > run it through a massive amount of QA before putting it into > production. > > Cf. http://qa.nuxeo.org/ for an example of what we do at Nuxeo. Sorry, I may have missed some context: of course upstream developers don't use Debian package's sources, they work directly on the development copy they have. 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. >> Probably other distributions make things differently because they >> are targeted to users with different needs. Other users could >> prefer the way maven works, so they will use maven to install their >> package. > > Maven is a build tool, not an installation tool. Just substitute the word "maven" with any installation tool you recommend for Nuxeo or whatever software we're talking about (including, for example, an APT repository different from the official Debian repositories). The key here is that there are many software installation tool and many different repositories for each one of these different tools. The software that goes in Debian's main archive is allowed to be there only if it complied with Debian policy. There are many good reasons to think that the Debian policy is a good thing and probably you have others to think that other ways would be better: however, people using Debian repositories expect that repositories to be compliant with the Debian policy, and probably this is a reason because of they choose them. If you think that some pieces of software would benefit from being redistributed under a different policy, then build a different repository. Pretending that it should enter Debian violation its policy doesn't benefit anyone (and, as a matter of facts, is not possible, because it would be rejected). >> About the difficulty of having a Java application in Debian, I >> cannot agree more with Tony: packaging things in Debian is >> difficult, because it requires some added value that the packager >> must put into the package, and added value requires time. > > This is not true, if the only thing needed was "some extra added > value" there would be 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? Of course, we could disagree on whether modifying a package to conform with Debian policy is an added value or not: sure, the perceived added value depends on what you want to do with a package and which are your priorities. Debian stated long ago its priorities and it'll continue to stick to them. Debian users are (or at least should be) aware of them: if the policy isn't good enough for their needs, they should probably find a different distribution. After all there are many distributions around just because different people had different ideas an what a distribution should be. 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. I fully understand that people not interested into Debian goals don't want to invest time in such goals. What I hope to have made clear is that I'm not pretending that you're package shouldn't enter Debian on a prejudicial position: I'm just clearing out what criteria we have to include a package or not. If you're interested in these criteria, you're in. Otherwise, I'm just warning you that Debian is not the right place for your packages. As I (and other people) already said, a personal APT repository would be better and it would require three lines of command instead of one. Not that bad loss... :-) >> This is true especially in the Java environment, where many >> programmers put very low attention to many things that Debian cares >> about (and that have been already discussed in this thread). I'm >> not discussing who is right and who is not (though I have an idea >> about it, but it could be significantly biased): simply, the two >> ways of work have very little intersection. > > We're talking about *open source* java developers, not just "java > developers" here. I didn't even consider the existence of Java non free software developers. > From my experience with working with both the Apache Foundation (I'm > with the incubating Apache Chemistry and Stanbol projects), and the > Eclipse Foundation (Eclipse Apogee, and a new project that willbe > announced today), I can guarantee you that their processes are as > annoying (or if you prefer, *rigourous* ;) that Debian's (wrt > licenses, copyright notices, etc.) Not about embedded library copies, for example (as far as I can tell). I'm not saying that Apache or Eclipse are working bad, but they're are working differently in some ways. But Debian is made the Debian's way, not Apache's way. >> And, unfortunately, one of the core philosophies in Debian is that >> we're not trading quality for time or package number: if the >> available resources (that is, people that contribute to Debian) are >> scarce, then what we're giving up is quantity, not quality. Usually >> we're also able to offer quantity, but it's not our main focus. >> >> BTW, in my little experience, I've already met at least two >> different pieces of software written in Java that were non free or >> even non redistributable because of licensing issues rising from >> putting JARs or copy and pasting code without checking if they were >> allowed to do so. I'm proud to say that, thanks to my work, now >> these pieces of software are really free in Debian: I'm sure this >> is not the only case, but it shows why all the thorough work that a >> Debian package needs it's useful. > > Were these projects from "reputable" organization such as Apache or > Eclipse, or open source vendors concerned with the quality of their > products and minimizing the legal risk attached to their products ? No, of course. But what does this change? From the point of view of me and many users, geogebra is much more important than JBoss, even it's not written by some big foundation. 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