On Sat, May 23, 1998 at 12:14:34AM -0700, Steve Lamb wrote: > On Sat, 23 May 1998 16:25:46 +1000, Anthony Towns wrote: > >The "other data" in Debian's case is stuff like dependency information, > >installation and removal scripts, and the maintainer's contact address. > Proprietary to Debian...
That's a very loaded word. In this context it comes close to offensive. [0] > >(That's more or less enough information to tell you what other programs > >you need to already have installed, anything special that you might have > >to take care of beyond just untar'ing it, and someone to email if you > >run into problems) > Which is generally in the README. Which I said. However that information *isn't* always included with prepackaged binaries, for the simple reason that such instructions are redundant: they've already been followed by the packager. To take the "tar" program as a simple example. /usr/doc/tar on my system contains three files: README.Debian which is basically a pointer to the upstream source, changelog.Debian.gz, and a copyright file. No INSTALL, no README, no nothing. Of course, "tar" doesn't require anything very special -- just libc6. "util-linux" could be more problematic, in that it requires ncurses3.4 and slang0.99.38 to be installed. It does include some READMEs, and even some installation instructions, at least for the login, init and getty programs. None of those mention ncurses or slang. > >Most of that's usually duplicated in /usr/doc/ directories, but since it's > >there and it can be useful, I think it's a good thing to let it be got at. > To the point of requiring another program to get at the archive that the > people want? I don't think so. Some tar's don't support the "z" option. Wouldn't it be better, therefore, not to gzip them, because that means they need another program to get at the archive they want? I don't think so. And, yes, I can see how this would be a problem if "ar" were an unusual sort of program to have on your system. And I don't doubt that there are systems out there that have tar but not ar or dpkg. I suspect, however, that most of those systems are either "I'm going to use this system for email, the GIMP and web browsing" RedHat installs, or "This system is my firewall. ls is a hacking tool" paranoia things. Both of which should, IMO, be being very careful about what they're doing, not finding precompiled binary packages *for other systems* and expecting them to work. Perhaps when there is a Linux distribution standard of some sort this might work, but... Well, colour me doubtful at the moment. > Here is why a lot of people are looking at SLP and liking it. > tar xzf blah.slp I thought I might try this myself. So I downloaded the smallest .slp I happened to stumble across from ftp.stampede.org, ummm, xslpc-0.75.slp. So I typed: ] [EMAIL PROTECTED] ~]$ tar tzf xslpc-0.75.slp And I got told: ] gzip: stdin: not in gzip format ] tar: Child returned status 1 ] tar: Error exit delayed from previous errors Now, as it turns out, xslpc.slp *is* actually a compressed-tar with some extra stuff on the end, it's just not gzip compressed: it's bzip2 compressed. So forgive me if I don't immediately concur with your analysis that the slp format is based on things which have "been the standard for years and years", while the deb format isn't. (This also gives me some concerns, ``So to extrace an .slp you just run tar xzvf *.slp, but if that doesn't work, you can use tar xIvf *.slp, and if *that* doesn't work, you might try tar xZvf *.slp, or...'') But to address your point rather than your rhetoric, what you seem to be saying is that slp would make a good "standard distribution mechanism", as tarballs currently are, and as Bruce's effort hopes rpm will be, with the added bonus that slackware users don't need to install any extra programs. And perhaps, in fact, it would. Perhaps Stampede should approach Bruce and co. [1] about seeing if this is possible. I don't know. Personally, though, I *really* *don't* *like* having packaging information hidden away so that only the packaging system can get to it. I *like* having everything stored in simple text based files, archived with standard archivers. That's the main reason why I prefer things like LaTeX and HTML to Word, RTF and Windows help. And yes, AFAIK, this applies to RedHat as much as Stampede. There's no way cruft(8), for example, would've gotten written if I hadn't been able to use things like sed and diff initially, and if dpkg hadn't left its various databases as plain text I'd never have been able to do that. Now, I haven't personally done any scripting that involved .deb's directly but I suspect being able to use things other than dpkg itself to get at the information therein is equally beneficial. So in short, yeah, being able to run tar over your packages and have it work just like in the good ol' days with Slackware is cool. It's not quite cool enough to overcome the crockishness of having to tack some funky structure onto the end of said tarball in a manner that it can only be gotten at by specialised tools though. IMHO, YMMV, FWIW, etc. Cheers, aj [0] http://www.gnu.org/philosophy/categories.html#ProprietrySoftware has this to say: ``Proprietry software is software that is not free or semi-free. Its use, redistribution or modification is prohibited, or requires you to ask for permission, or is restricted so much that you effectively can't do it freely.'' [1] Whoever that "co." may be. -- Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. PGP encrypted mail preferred. ``It's not a vision, or a fear. It's just a thought.''
pgppu5T1fo9MY.pgp
Description: PGP signature