On Wed, Dec 26, 2007 at 04:32:39PM +0000, Neil Williams wrote: > On Wed, 2007-12-26 at 14:23 +0100, Wouter Verhelst wrote: > > On Sun, Dec 23, 2007 at 07:17:16PM +0000, Neil Williams wrote: > > > I'd just add: > > > * it isn't in the spirit of free software to make it hard for others to > > > use the code - making a package Debian-native when it could work on any > > > GNU/Linux or POSIX platform makes it unnecessarily hard for a Fedora or > > > Gentoo user etc. to package the code and maintain it in their own > > > distro. > > > > Sorry, but that's totally wrong. Nobody every told anyone to use the > > debian/ directory for anything. > > That's not the point. It hinders sharing the code.
"rm -rf debian/" There. That was hard. > I'm not unaware of the issues here, I'm upstream for many of my Debian > packages and only a few are native. I make double uploads because it > helps people package my upstream code for Fedora and SuSE and I > believe that free software should never hinder the sharing of code. I do not agree that having double uploads makes it easier to share code. YMMV, of course; but you can't deny that someone building an RPM package can ignore a debian/ directory as easy as I can ignore a .spec file when building a Debian package. > Releasing code with the debian/ directory intact, just complicates the > work for other distros. If they build an RPM file, having a debian/ directory does not make matters harder. If they are doing a Debian derivative, the debian/ directory would probably not complicate matters. > We complain when upstream have a borked debian/ directory in the > .orig.tar.gz yet it's not our problem if, upstream, we do the same to > others? Ah, but there's a difference. If you're releasing your code as a Debian package, then your debian/ directory probably gets quite a bit of your attention; so the idea that it would be "borked" is pretty unlikely. I complain when upstream has a *borked* debian/ directory. Personally, I don't think it's that bad if they have a good and working debian/ directory. [...] > > > How are they to know whether the latest native version is Debian > > > specific or contains useful "upstream" improvements? > > > > By reading debian/changelog -- that's what it's for! > > So they have to download the new *debian* version just to see what has > changed when if it was an SF project they could see that the Debian > release is of no interest to them as they have the .orig.tar.gz. Why > should people wanting to use your code have to watch (and understand) > Debian practices to package your POSIX code for a different > distribution? What about forcing others to make repeated (useless) > downloads and wasting their time reading Debian webpages / changelogs, > trying to pick out what they want from the Debian stuff they don't? The > package can be used outside Debian - why should someone outside Debian > need to read debian/changelog in the first place! If you really want, there's no reason why you can't symlink ChangeLog to debian/changelog. The point wasn't that they should have to understand how debian/changelog works; the point was that they should understand that the whole idea of a changelog is to document changes. Whether it's in one location or another doesn't really matter. Also, the changelog is just one way. 'rm -Rf foo/debian foo.old/debian; diff -Run foo.old foo' works just as well. Moreover, I do consider it good taste to have proper versioning; if an upload is done that only contains minor packaging adjustments, the versioning should reflect that, so that other packagers can see this. This isn't something Debian-specific, BTW. I do think that if you make an upload which, say, only contains a few minor fixes to the build system which will make it build on more systems, but not change anything on those systems where it already builds, that this should be reflected in the build system; so that people who've packaged it and have no issues, should not necessarily have to update the package. That's just a matter of communicating with your downstreams. > If the code is not dependent on Debian itself, why should someone from > another distribution even need to know about how Debian works just > because upstream happens to be a DD? They shouldn't. But making a package a debian-native package does not include that requirement. If you as a Debian Developer are a straight jackass who doesn't give a shit about your downstreams, making their life as hard as humanly possible, then you're right. But there's no reason why anyone should do that; and I do think it's possible to just make a few agreements with your downstreams (which you could document in, say, a README file) regarding versioning and packaging. Why should I be required to jump through extra useless hoops just because my downstreams are too lazy to *ignore* a directory which is perfectly innocent and irrelevant to them? In addition, Debian is well-mirrorred all over the world (even better than SF, I'd say, though I don't have any numbers to back that up), to the extent that FreeBSD and other projects are using Debian mirrors as a source of source tarballs. Moreover, downloading something from a Debian mirror can be done with simple FTP and/or HTTP clients; for SF.net's mirrors, there's this annoying download frontpage, making the actual download slighlty more involved (it's possible to directly wget if you know the correct path of a source tarball; but since SF.net's mirrors don't show directory listings, this is not as straightforward). So I'd say that by packaging something for Debian (and Debian alone), you're actually providing your downstreams a service. > All they care about is getting the upstream code to work in Fedora or > PCLinuxOS or gentoo or wherever. It takes months to learn all the ins > and outs of Debian packaging - why make that a requirement for other > distributions to package the upstream code? I never said you should do that. I only said that whether a package is Debian-native or not does not make anything harder for a downstream packager. > Write portable code in the first place and help others. What's wrong > with that? Nothing! I never said otherwise! > > gdome2-xslt isn't the only package that's debian-native while not being > > debian-specific. > > Which, of course, doesn't make it right so to do. Things can change and > just because, historically, it happened one way does not mean that it > should continue that way. We have guidelines for use of native and > non-native packages, the distinction confuses lots of new packagers > (common refrain on the d-mentors list) and it would help Debian, new > maintainers and other distributions if we adopted a standard way of > dealing with the division that has more intrinsic logic than "the DD > felt like doing it that way". There are many places in Debian where we work this way; I don't think that will ever change, nor do I think it is a problem, as long as it doesn't cause any problems. In other words, I don't think this can be an argument in and of itself. > Debian should be more friendly to upstream development - one way of > doing that is by ensuring that we only keep to ourselves packages that > are genuinely dependent on Debian itself. Yes, that's true. But making a package Debian-native does not mean we 'keep it to ourselves'. > Then, when DD's write useful code that requires other bits written by > other DD's, Fedora can pick it up and use the same code themselves, > etc. If one of those dependencies is Debian-native, it wastes time, > hindering upstream development on other projects which, eventually > bites Debian in the rear. (e.g. by forcing upstream to come up with > dirty hacks to do what could be done in a sane way if the relevant > Debian package was available to them). Debian-native packages *are* available to non-Debian people. Offlineimap, for instance, has been available in the FreeBSD ports tree for ages. > I strongly believe that free software should be distro-neutral by design > and in implementation. Just like the "any-browser" campaign and the like > - making a package native to any one distribution should be an absolute > last resort. We don't disagree here. We only disagree in that I do not think a debian native package makes a package unavailable to non-Debian distributions. > So it causes an extra upload for upstream releases? So? Wow, that is a > lot of work, really taxing the brain cells .... Have you ever done a file release on SF.net? First you have to upload the files, through FTP. Then you have to "create" the release (few HTTP page hits to get to the "File release system", and to actually create said release). Then you have to upload the changelog and/or the release notes (HTTP page hit for each). Then you have to select the files (HTTP page hit), and for each file set the type of the file (HTTP page hit per file). Finally, you have to click the "Yes, I'm ready, please send the email announcements out (another HTTP page hit). If their servers are loaded, this is likely to take half an hour or so of useless, tedious, manual work. I truly hate that interface. In contrast, a Debian upload is very simple: once my builds work and are tested, I simply run debsign and dupload on the .changes files. That takes all of, oh, 5 seconds. Obviously, one could upload their files to a private place, but then you don't have mirroring. So why not use the Debian mirror network? > Some native packages even 'make install' directly into debian/tmp/ - how > unfriendly is that?! Very. This, indeed, should be strongly discouraged. I never tried to defend this type of thing. But making a package Debian-native doesn't have to imply that kind of jackass-behaviour. > It's about reuse of code, it is about sharing code and about not > thinking of Fedora et al as "competition" or a "burden" but as > colleagues, even friends - people who help us from time to time and who > should get some help in return. > > Whatever we think, there will not come a time when every GNU/Linux user > is a Debian user - choice doesn't work that way. We can't convert > everyone to the Debian way, so why not support others who are actually > on the side of free software but just happen to use a different > GNU/Linux distribution? I fully agree on those bits. > > There's no reason why we should force maintainers to do more work to > > upload their software twice, just because some people think doing a > > native package for non-debian-specific code is ugly. It isn't. > > I believe it is ugly, it is unfriendly and it hinders adoption of > upstream packages into other distributions. > > Which would you rather package for Debian - a package that has a borked > debian directory and lots of other fluff about rpm's and emerge or a > simple, clean .orig.tar.gz? I don't even consider that when deciding whether to package something. My only factors are: code quality, upstream responsiveness and helpfulness, and usefulness of the code itself. In fact, having specfiles and debian/ directories and emerge stuff in a source tarball probably means that upstream wants to make their users' life as easy as possible, so I'd probably consider that a point in their favour. [...] I think we've been talking right next to eachother. You seem to say that code which is not Debian-specific should be available to non-Debian people. I couldn't agree more! If something is useful to a greater audience, there's no reason why it should only be available to Debian people. The major difference, I feel, is in that you seem to associate debian-native packages with poor and inflexible build systems; that this is acceptable as long as the package is used in Debian alone, but that, since we don't want downstream users of our code to have to use poor and inflexible build systems, we should somehow discourage debian-native packages. My answer is pretty simple: I do not think that poor and inflexible build systems are acceptable, *ever*. When I want to work on some code, I may want to temporarily install the software in some other location, in order to not completely hose my development system without having to resort to the waste in disk space of a chroot environment. When I want to prepare a patch to some debian-native package, I may want to have the build system temporarily use other build flags, without having to resort to Makefile hackery which I will then most likely forget to remove before creating said patch. Indeed, I think that *all* code in Debian, even the so-called "Debian-specific" bits, should have proper and flexible build systems, making them easily usable on non-Debian distributions for as much as is reasonably possible. After all, who are we to decide when something is "useful" beyond Debian? People have already thought that apt was useful enough for it to be ported to RPM, and that dpkg was useful enough for it to be ported to MacOS X. Who is to say that nobody will ever think the buildd suite, debian-cd, or debbugs, are useful enough for them to be ported to other systems? If you are saying that poor and inflexible build systems have no place in code that is not Debian-specific, then I heartily agree, and I'll go further to say that this is also true for code that *is* Debian-specific. If, however, you're saying that debian-native packages, by definition, contains poor and inflexible build systems and that therefore they should be avoided at all cost, then with all due respect, I'd think you'd be a lunatic. -- <Lo-lan-do> Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
