[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian from the Stampede's POV



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:

] [aj@azure ~]$ 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 <aj@humbug.org.au> <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.''

Attachment: pgpfFgmwS9eDj.pgp
Description: PGP signature


Reply to: