[EMAIL PROTECTED] (Bruce Perens) writes: > Without arguing any more, I think it's fair to say that I'd want to > look really hard at some alternatives before the project chooses a > source package format. I'd be listening to Ian Jackson's opinion, > since Ian is the author of dpkg and now has time for the project again. > I'd give a lot of weight to Klee's opinion too, especially since Klee has > been working on this problem for a while and has his own design to talk > about.
I'm not asking for the project to adopt the source format yet. I just want some technical feedback on whether or not it is a good design. (By the way, the letters "RFC" stand for Request For Comments) I'm interested in Klee's design too, but I've been waiting for close to a year for it. I hope he's not trying to implement it before he asks for comments. Funny that there has been so much negative reaction -- and nobody has even bothered to download the samples I put up yet. Most of the debate so far has just been a knee-jerk reaction to somebody trying to shake up the status quo. I'm quite disappointed in the level of technical debate. But I guess that's to be expected - technical debate is much more boring than politics and taking sides. > My personal opinion is that we need something that builds on the work > that has already gone into dpkg-source. Build a single file containing > all of the separate files of the dpkg-source packages. Make it unnecessary > to rename the original source file. Add to that binary dependencies. You'd > have all I think is necessary. You obviously like dpkg-source. I, on the other hand, hate it. I've wasted several useless days wrestling with it while I've been a developer. Do you want to take over the JDK package? You'll quickly learn how fun dpkg-source really is. Also, you might want to try unpacking some dpkg-source files at random from the archive. It's pretty easy to make a source package that won't unpack. You can blame the developers, but dpkg-source is the real problem. Try adding a binary file (ie. a jpeg) to a Debian package - you'll find you need to uuencode it for dpkg-source to take it. Not to mention the fact that dpkg-source on bo can't unpack source files from hamm (because of a problem with patch). I can't see how slapping a couple more layers of hacky code onto it is going to make it any better. It's just a bad design. I personally find it much more embarrassing than dselect, because it shows that we are lacking technically at our core. And you want to perpetuate it? My argument is that we don't need to enhance dpkg-source at all. Just throw it in the garbage. All that functionality (and more) already exists in dpkg and the .deb file format. Including dependencies. (calling 'em source dependencies is just a red-herring) Oh yeah, you're going to get a rough ride from me if you want a file format with all the source (upstream and debian) in a single source archive. If that happens, everytime somebody changes a description or a debian/rules file, the entire source package will have to be re-downloaded. I'd estimate that would probably triple or quadruple the time it takes me to mirror the Debian sources (I've only got a 28.8 net connection). Red Hat does that - but it is a bad design. PLEASE, somebody download my demo and really try it out! I'm pleading with you guys. I'm sure there are lots of things that could be improved. I didn't really like some of the names I came up with for the variables - maybe somebody's got some better ideas. Maybe somebody could come up with a competing proposal (not just talk). I want some real feedback, not uninformed opinion. (Sorry, Bruce.) Cheers, - Jim
pgprw79vbdter.pgp
Description: PGP signature
