This is written by an 18 year old software developer who has an interesting
idea in 'autopackage.'
http://www.osnews.com/story.php?news_id=2307&page=1

This next piece talks about the Linux Desktop Base and also has some good
ideas.
http://www.newsforge.com/article.pl?sid=04/07/15/190253

I know that package management is not a great concern to most users of
Slackware, but I thought it might be of interest to some of those who like to
'keep up' on what is going on outside of "Slackworld" (not to be confused
with "Mendoworld" ... for those who live in N. CA and know what I'm talking
about.)

ANC

Al C. <no.spam.acanton@adams-blake.no.spam.com> wrote:
> This is written by an 18 year old software developer who has an interesting
> idea in 'autopackage.'
> http://www.osnews.com/story.php?news_id=2307&page=1

This article is irrelevant as Slackware does not have the issues which the
author is ralying against. I think Slackware's solution is the simplest
for the advanced user: you sort out the dependancies. If you don't have
them, the package doesn't work. Names of the packages don't matter, just
the files they deposit (as to where to deposit them, this is where open
standards come in). Slackware also avoids what the author calls "RPM hell"
by this approach. There are advantages to nixing all dependancy checks and
putting that responsibility back into the hands of the user. This is one
of them.

> This next piece talks about the Linux Desktop Base and also has some good
> ideas.
> http://www.newsforge.com/article.pl?sid=04/07/15/190253

Slightly more relevant, but really not so much since Slackware doesn't
care about dependancies in the package tools. The article seems to be
promoting a standard to allow people to convert to something like
Slackware's package tools (no dependancy checks in the package management
software) but not have to worry about checking for the presence of
dependant files because the standard specifies they are there. Nice
concept but it will be a rather hairy mess to manage. I would argue that
there's already a core de facto standard in things like glibc, gcc and
other very standard libraries. Packages which depend solely on these core
files would be fine, but what about specialized tools? These would likely
require libraries that are not in the core standard file and the article
says in such situations the libraries would be bundled with the package.
But what if the user already has these libraries? We've just wasted their
download time and bandwidth having them download a huge package with
libraries they didn't need. In Slackware, this would not be an issue. The
package maintainer would just say "you need xyz version a.b.c or greater,
here's a link" and then you'd be responsible for seeing if you needed the
file or not. The article is also wrong when it says there's no way to
uninstall from a tarball, as we should all know from Slack's package
tools.

> I know that package management is not a great concern to most users of
> Slackware, but I thought it might be of interest to some of those who like to
> 'keep up' on what is going on outside of "Slackworld" (not to be confused
> with "Mendoworld" ... for those who live in N. CA and know what I'm talking
> about.)

I really don't care what the other distros are doing to sugarcoat the
package management process as long as their standards are open so I can
extract the files to whatever format I decide to use. These articles are
geared at bringing in the average know nothing person. This is not who
Slackware is geared for. I personally think there's room enough in the
Linux arena for both neophytes and experts. One of the advantages of Linux
distributions is the wide range of appraoches used so you can pick and
chose one which suits you best. Should the other distributions chose to
use these tools, fine for them. I think Slackware is just fine the way it
is. The only addition may be a tool similar to rpm2tgz for whatever
package system comes up next. Remember that dependancy hand-holding for
Grandma Joe is not what Slackware is about. Slackware is for the power
user who a) knows what dependancies are and b) knows how to check for them
and c) makes sure they're all met without needing some automated tool to
do the thinking for them. Slackware also allows one to mix and match
packages with the old "make;make install" bit, which I prefer. I don't
particularly care to have to jump through hoops created by some "helpful"
packaging system just to install something on my machine that happens to
only be distributed by source instead of the package management system of
the day. I use a lot of older code that only comes in source tarballs. I
need not some automagic system getting in my way of make;make install.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Al C. wrote:

> This is written by an 18 year old software developer who has an
> interesting idea in 'autopackage.'
> http://www.osnews.com/story.php?news_id=2307&page=1

I'm not convinced, it just seems to be a more thought out RPM system really.
It won't really fix binary compatibility problems (if there isn't a package
for your particular GCC version your still stuck) and it won't solve
problems like project renaming (or major forks, xfree86 -> xorg for
example).

I can't see these problems being resolved and working neatly with the
variety of programming languages and system layouts around.

> This next piece talks about the Linux Desktop Base and also has some good
> ideas.
> http://www.newsforge.com/article.pl?sid=04/07/15/190253

This is closer to a real world solution, but politics will get in the way.

Personally, I'm beginning to come around to the Mono project's way of
thinking. It's more pure than Java (i.e. FOSS[0], unless Sun do the decent
thing and free up it's baby) and it kills two birds with one stone; makes
it easy for the programmer and makes it easy for the user.

So long as the programmers favorite language is supported by a Mono compiler
they're happy. And the users gets a unified way of installing and running
the program. Without having to worry about binary compatibility,
dependencies will become easier to handle. Of course it'll never be totally
simple, but it's a big step in the right direction.

Blumf

[0] I still worry about MS's patents though. Time will tell.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFBBt+gMid3IcxolsoRAqxGAJ9Y5F0c+i61qbYrHaCN9h 97pzWf0QCfadMk
NH5ZiKJNT/s3EUGGuY8v/GU=
=OUU1
-----END PGP SIGNATURE-----