Red Hat's RPM v. SlackWare's packages?

Red Hat's RPM v. SlackWare's packages?

Post by Arcadio Alivio Since » Mon, 01 Jul 1996 04:00:00



        I downloaded the RPM package off of Red Hat's web site just to
see what all the hype was about concerning RPM.  Frankly, I wasn't really
impressed.  In fact, I was down right turned off by it.  SlackWare's
system of packages to keep track of installed software seems to be a much
easier and straightforward method than RPM.

        And creating custom SlackWare packages seems to be a bit easier
than creating custom RPMs as well.  There seems to be a whole of *you
gotta do in setting up an RPM while in SlackWare, all you do is
"installpkg -m <package_name>".  

        Would anybody care to comment on this?  Am I missing something,
or is RPM not all that it's cracked up to be?

--
===============================================================================
Arcadio Alivio Sincero, Jr.
Sophomore, Computer Science Major at the University of Maryland at College Park
Amateur competitive bodybuilder

"D.A.R.E. .... to keep cops off donuts."

 
 
 

Red Hat's RPM v. SlackWare's packages?

Post by Donnie Barn » Mon, 01 Jul 1996 04:00:00


Quote:>    I downloaded the RPM package off of Red Hat's web site just to
>see what all the hype was about concerning RPM.  Frankly, I wasn't really
>impressed.  In fact, I was down right turned off by it.  SlackWare's
>system of packages to keep track of installed software seems to be a much
>easier and straightforward method than RPM.

>    And creating custom SlackWare packages seems to be a bit easier
>than creating custom RPMs as well.  There seems to be a whole of *you
>gotta do in setting up an RPM while in SlackWare, all you do is
>"installpkg -m <package_name>".  

>    Would anybody care to comment on this?  Am I missing something,
>or is RPM not all that it's cracked up to be?

Yes, RPMs are a little more difficult to build.  But, you sure get a
hell of a lot if you take the time.  Can you verify that your Slackware
packages are still the same months after you install them?  Can you
upgrade a package IN PLACE while still maintaining your hard earned
config files?  Can you verify EVERY package on your system with one
command?  Can you PGP verify that the package you downloaded was the
one that we (or Slackware in this case) built?  No.  Nada.

Tarfiles with post install scripts are fine for many things, but for
maintaining a real *nix system in a production environment they are
sorely defficient.  Also, RPMs build SRPMs that are rebuildable with
ONE command.  Want to rebuild all your RPMs on the system to use
a new libc?  Go to your SRPMs dir and do 'rpm --rebuild *.src.rpm'.
Then go install the new RPMs.  Can't do that with Slackware packages
(especially considering there really is no such thing as a Slackware
source package).  

You also can't FTP install a new Slackware package off the net with
one command.  You can't query a Slackware package to see what's in it
before you install.  You can't query a Slackware package and have it
tell you which files are config files or documentation.  That's a
*very* nice feature.  If you install a new RPM and don't know how
to use it, you just do 'rpm -qd <package name>' and it will tell you
which files it installed are documentation for it (all man pages,
info pages, and /usr/doc documentation).

I'm certainly not bashing Slackware here...but RPM is a superior
package management system to tar files if you need extra features.
Many folks don't, and that's okay.  Many folks do, and they're glad
we've written RPM to help them out.

--Donnie

--

*    See my web page for my personal list of items for sale in Cary, NC   *
---------------------------------------------------------------------------
From _Things You'd NEVER Expect A Southerner To Say_ by Vic Henley:    
***     Careful, that may be a fire hazard.

 
 
 

Red Hat's RPM v. SlackWare's packages?

Post by David M. Co » Tue, 02 Jul 1996 04:00:00



Quote:>    I downloaded the RPM package off of Red Hat's web site just to
>see what all the hype was about concerning RPM.  Frankly, I wasn't really
>impressed.  In fact, I was down right turned off by it.  SlackWare's
>system of packages to keep track of installed software seems to be a much
>easier and straightforward method than RPM.

That's odd.  I find adding/removing/upgrading RPMs really easy using
glint.  I find it particularly easy to keep things up to date.  I haven't
tried making my own RPMs yet.

I do wish Redhat would put something about dependencies at least in the
descriptions of the packages.  Debian is superior to Slackware and Redhat
in this regard, though not as user-friendly.

Dave Cook  

 
 
 

Red Hat's RPM v. SlackWare's packages?

Post by Erik Tro » Tue, 02 Jul 1996 04:00:00



>I do wish Redhat would put something about dependencies at least in the
>descriptions of the packages.  Debian is superior to Slackware and Redhat
>in this regard, though not as user-friendly.

These will be in the next release of RPM.

Erik

-------------------------------------------------------------------------------
   Always hoped that I'd be an apostle. Knew that I would make it if I tried.
     Then when we retire we can write the gospels so they'll all talk about
         us when we die. - "The Last Supper" from Jesus Christ Superstar

 
 
 

Red Hat's RPM v. SlackWare's packages?

Post by John Bro » Fri, 05 Jul 1996 04:00:00





>>I do wish Redhat would put something about dependencies at least in the
>>descriptions of the packages.  Debian is superior to Slackware and Redhat
>>in this regard, though not as user-friendly.
>These will be in the next release of RPM.

The Debian 1.1 announcement included this comment:

        Debian's aim is to work together with other Linux developers
        rather than compete with them. For example, we encourage all
        creators of Linux distributions to take components from Debian.
        We are aware of the parallel work that Red Hat has done on
        packaging systems, and would like to come to some sort of
        package merge with them.

It would be nice to have one universal Linux packager.  Any chance of
this happening, or are they just dreaming?
--
John Brock

 
 
 

Red Hat's RPM v. SlackWare's packages?

Post by Arcadio Alivio Since » Sun, 07 Jul 1996 04:00:00


: Yes, RPMs are a little more difficult to build.  But, you sure get a
: hell of a lot if you take the time.  Can you verify that your Slackware
: packages are still the same months after you install them?  

        Well ... I suppose one could check the package logs of SlackWare
and see if those files are still in place to achive the same effect ....

        The biggest problem I have with RPM is the fact that it appears
you need to get the software already in RPM form.  That's where the real
benefits of RPM shine through.  However, even though I'm currently using
SlackWare Linux, *none* of the third party software I have installed were
obtained in SlackWare package form.  I had to create SlackWare packages
out of the third-party software packages so I can utilize SlackWare's
pkgtool mechanism.  However, since creating SlackWare packages is
practically painless, this wasn't such a bad thing.  Which is why I griped
about the pains of making a custom RPM.

        What are the chances of obtaining Linux software in RPM form?
From what I can tell, not very good.  It'd be nice 'tho.  Then I wouldn't
have any problem with RPM (since I wouldn't need to make my own custom
RPMs).  But *most* Linux software is distributed in source form.  Some are
in pre-compiled binary form 'tho, but you still have to do a manual
install.

        The reason for using any packaging system (at least the reason
why *I* use them) is too keep track of my installed software.  Mainly to
ease upgrading them (since a lot of UNIX software packages tends to be
scattered throughout the filesystem, this make some kind of software
accounting system a necessity).  However, I'm wondering ... why use a
packaging system at all?  Why not do it like you would do it in DOS or
OS/2 ... install the software entirely in it's own directory.  Then when
you wanna upgrade the software, just delete the directory.  Or in other
words, just keep all the parts to the software in one place not have one
part in /usr/bin, then another part in /usr/lib and then yet another part
in /usr/etc or /etc, etc., etc..  This sounds like it would definantly
make things easier.  I'm curious to know why, it seems, this method has
not be adopted.

--
===============================================================================
Arcadio Alivio Sincero, Jr.
Sophomore, Computer Science Major at the University of Maryland at College Park
Amateur competitive bodybuilder

"D.A.R.E. .... to keep cops off donuts."

 
 
 

Red Hat's RPM v. SlackWare's packages?

Post by Alan V. Shackelfo » Sun, 07 Jul 1996 04:00:00



: accounting system a necessity).  However, I'm wondering ... why use a
: packaging system at all?  Why not do it like you would do it in DOS or
: OS/2 ... install the software entirely in it's own directory.  Then when
: you wanna upgrade the software, just delete the directory.  Or in other
: words, just keep all the parts to the software in one place not have one
: part in /usr/bin, then another part in /usr/lib and then yet another part
: in /usr/etc or /etc, etc., etc..  This sounds like it would definantly
: make things easier.  I'm curious to know why, it seems, this method has
: not be adopted.

I don't think it is possible. Most unix software relies very heavily on
shared libraries and other common elements to work properly. These parts
are located so all the processes that need them can access them. If every
program on a unix filesystem was 100% complete on its own, you would need
a huge disk drive to contain them all, since certain basic ingredients
would exist in hundreds of locations instead of just one. On the other
hand, if the developers attemted to offer pre-compiled binaries for every
conceivable configuration of hardware that exists out there, we would
never be able to find what we need, because each program and all of
its variations would require an ftp area of its own. As long as we, the
users, insist on running Linux on every pieced-together home made box
known to man, the current system of dependant elements is probably a
necessary evil.
--
One net to rule them all, one net to find them, one net to bring them all

 
 
 

Red Hat's RPM v. SlackWare's packages?

Post by Donnie Barn » Mon, 08 Jul 1996 04:00:00


Quote:>: Yes, RPMs are a little more difficult to build.  But, you sure get a
>: hell of a lot if you take the time.  Can you verify that your Slackware
>: packages are still the same months after you install them?  

>    Well ... I suppose one could check the package logs of SlackWare
>and see if those files are still in place to achive the same effect ....

Uh, no, you can't.  I mean *verify*.  I mean check to see that they
are the *same* as the file you installed originally.  Check to see if
they have the same owner and group.  Check to see if they have the
same permissions and aren't mysteriously suid root.  Check to see
if they have the same major and minor number (if a device).  

Quote:>    The biggest problem I have with RPM is the fact that it appears
>you need to get the software already in RPM form.  That's where the real
>benefits of RPM shine through.  However, even though I'm currently using
>SlackWare Linux, *none* of the third party software I have installed were
>obtained in SlackWare package form.  I had to create SlackWare packages
>out of the third-party software packages so I can utilize SlackWare's
>pkgtool mechanism.  However, since creating SlackWare packages is
>practically painless, this wasn't such a bad thing.  Which is why I griped
>about the pains of making a custom RPM.

We understand.  But, it isn't hard to make binary only RPMs like
Slackware tar files, it just takes a little more input.  If you have a
file list of installed files you can create a binary RPM in a couple
minutes.  

Quote:>    What are the chances of obtaining Linux software in RPM form?
>From what I can tell, not very good.  It'd be nice 'tho.  Then I wouldn't

Not good?  The JDK was in RPM format really early.  You can buy BRU
and get it in RPM format.  You can buy Motif and get it in RPM format
(from Red Hat *or* from Metro Link).  More and more companies are using
it.  Oh, and Red Hat Software has over 400 (maybe even 500) RPMs available
from our FTP site.  Just about anything freely available has already
been done and uploaded to our site by someone.

Quote:>have any problem with RPM (since I wouldn't need to make my own custom
>RPMs).  But *most* Linux software is distributed in source form.  Some are
>in pre-compiled binary form 'tho, but you still have to do a manual
>install.

*Most* Linux software has already been RPM'ed and is waiting for you
at ftp.redhat.com.

Quote:>    The reason for using any packaging system (at least the reason
>why *I* use them) is too keep track of my installed software.  Mainly to
>ease upgrading them (since a lot of UNIX software packages tends to be
>scattered throughout the filesystem, this make some kind of software
>accounting system a necessity).  However, I'm wondering ... why use a
>packaging system at all?  Why not do it like you would do it in DOS or
>OS/2 ... install the software entirely in it's own directory.  Then when
>you wanna upgrade the software, just delete the directory.  Or in other

Yuck.  That stinks.  A completely installed Red Hat system would
need 300 different directories with all of it in your path.  Yuck.

Quote:>words, just keep all the parts to the software in one place not have one
>part in /usr/bin, then another part in /usr/lib and then yet another part
>in /usr/etc or /etc, etc., etc..  This sounds like it would definantly
>make things easier.  I'm curious to know why, it seems, this method has
>not be adopted.

Because it's inherently broken.  Read the Linux File System Standard
sometime (it's on sunsite).  

--Donnie

--

*    See my web page for my personal list of items for sale in Cary, NC   *
---------------------------------------------------------------------------
From _Things You'd NEVER Expect A Southerner To Say_ by Vic Henley:    
***     Careful, that may be a fire hazard.

 
 
 

Red Hat's RPM v. SlackWare's packages?

Post by Arcadio Alivio Since » Mon, 08 Jul 1996 04:00:00




: : accounting system a necessity).  However, I'm wondering ... why use a
: : packaging system at all?  Why not do it like you would do it in DOS or
: : OS/2 ... install the software entirely in it's own directory.  Then when
:
: I don't think it is possible. Most unix software relies very heavily on
: shared libraries and other common elements to work properly. These parts

        You would keep the shared libraries in /lib like you're supposed
to.  But keep the main executable, configuration files, etc., in it's own
directory ... possibly under /usr.  This is similar to how in M$ Windoze,
you put all the DLLs in \WINDOWS (or was it \WINDOWS\SYSTEM?) and under
OS/2, they go under \DLL (or any directory listed in your DLLPATH).  

        How about that?

        Also, keep the man pages in the same directory as the main
executable, configuration files, etc. .. (like if your application is in
/usr/myapplication, put them in /usr/myapplication/man) and just add that
path your MANPATH.  

        Doing it this way would eliminate the need for a packaging system
for most, home PC-based, situations.  Possibly for large UNIX
installations as well (ok ... maybe not ...).

--
===============================================================================
Arcadio Alivio Sincero, Jr.
Sophomore, Computer Science Major at the University of Maryland at College Park
Amateur competitive bodybuilder

"D.A.R.E. .... to keep cops off donuts."

 
 
 

Red Hat's RPM v. SlackWare's packages?

Post by Arcadio Alivio Since » Mon, 08 Jul 1996 04:00:00


: >: Yes, RPMs are a little more difficult to build.  But, you sure get a
: >: hell of a lot if you take the time.  Can you verify that your Slackware
: >: packages are still the same months after you install them?  
: >  Well ... I suppose one could check the package logs of SlackWare
: >and see if those files are still in place to achive the same effect ....
: Uh, no, you can't.  I mean *verify*.  I mean check to see that they
: are the *same* as the file you installed originally.  Check to see if
: they have the same owner and group.  Check to see if they have the
: same permissions and aren't mysteriously suid root.  Check to see
: if they have the same major and minor number (if a device).  

        Ok, you've made your point with this one.

: We understand.  But, it isn't hard to make binary only RPMs like
: Slackware tar files, it just takes a little more input.  If you have a
: file list of installed files you can create a binary RPM in a couple
: minutes.  

        Really?  Hmm ... perhaps I need to play around with RPMs some
more.  I apparently need to upgrade my version of cpio 'cause RPM is
sending it a "--quiet" switch and my copy of cpio doesn't understand it.  
(Like I mentioned earlier, I'm using SlackWare 3.0).

: Not good?  The JDK was in RPM format really early.  You can buy BRU
: and get it in RPM format.  You can buy Motif and get it in RPM format
: (from Red Hat *or* from Metro Link).  More and more companies are using
: it.  Oh, and Red Hat Software has over 400 (maybe even 500) RPMs available
: from our FTP site.  Just about anything freely available has already
: been done and uploaded to our site by someone.

        Hmm ... I've heard that it's good to learn something new
everyday.  Perhaps I've should've looked before I leaped.

: *Most* Linux software has already been RPM'ed and is waiting for you
: at ftp.redhat.com.

        Yes, but what about non-Linux specific software?  I don't feel
comfortable with having to rely on somebody else to have already made an
RPM for me.  But as long making custom, binary-only, RPMs is easy and
relativly painless, then I wouldn't have to worry if an RPM is available
or not.  I'm gonna start experimenting some more ...

: >packaging system at all?  Why not do it like you would do it in DOS or
: >OS/2 ... install the software entirely in it's own directory.  Then when
: >you wanna upgrade the software, just delete the directory.  Or in other
: Yuck.  That stinks.  A completely installed Red Hat system would
: need 300 different directories with all of it in your path.  Yuck.

        One could put a link to the main executable in /usr/bin so you
wouldn't have to put the directory in your path.  However, if someone
were to do with the man pages like I suggested in my other post, I
suppose the MANPATH would grow extremly large in a short time.

: >in /usr/etc or /etc, etc., etc..  This sounds like it would definantly
: >make things easier.  I'm curious to know why, it seems, this method has
: Because it's inherently broken.  Read the Linux File System Standard
: sometime (it's on sunsite).  

        I have.  And I don't see why parts to a single application has to
be scattered throughout the filesystem.  How does this benefit anybody?  
I say continue to keep "system dependent stuff" in thier normal locations
in /bin, /lib, /etc (only *system* config files should go here), and
/sbin.  But other software, be placed in thier own directories under /usr.

        Hmm ... I guess this post is starting to move out of the "RPM v.
SlackWare packages" argument and instead moving to how the Linux
filesystem should be setup.  I think my argument above is a good one and
I'd like to see what's wrong with it.

--
===============================================================================
Arcadio Alivio Sincero, Jr.
Sophomore, Computer Science Major at the University of Maryland at College Park
Amateur competitive bodybuilder

"D.A.R.E. .... to keep cops off donuts."

 
 
 

Red Hat's RPM v. SlackWare's packages?

Post by John Bro » Mon, 08 Jul 1996 04:00:00





[...]
>: >packaging system at all?  Why not do it like you would do it in DOS or
>: >OS/2 ... install the software entirely in it's own directory.  Then when
>: >you wanna upgrade the software, just delete the directory.  Or in other
>: Yuck.  That stinks.  A completely installed Red Hat system would
>: need 300 different directories with all of it in your path.  Yuck.
>    One could put a link to the main executable in /usr/bin so you
>wouldn't have to put the directory in your path.  However, if someone
>were to do with the man pages like I suggested in my other post, I
>suppose the MANPATH would grow extremly large in a short time.
>: >in /usr/etc or /etc, etc., etc..  This sounds like it would definantly
>: >make things easier.  I'm curious to know why, it seems, this method has
>: Because it's inherently broken.  Read the Linux File System Standard
>: sometime (it's on sunsite).  
>    I have.  And I don't see why parts to a single application has to
>be scattered throughout the filesystem.  How does this benefit anybody?  
>I say continue to keep "system dependent stuff" in thier normal locations
>in /bin, /lib, /etc (only *system* config files should go here), and
>/sbin.  But other software, be placed in thier own directories under /usr.

I think what may be "inherently broken" is the basic Unix model, where
you search for executables and other support files in a "path" of
directories.  There is nothing inevitable about doing things this way,
it just happened to be what made sense to the people who first designed
Unix (or whoever they got the idea from), and since then it has been
passed down from generation to generation, even unto the present day.
There are many arbitrary choices that go into designing an operating
system, and many paths that could have been taken, but weren't.  I'm
sure that if someone were designing an operating system from scratch it
would be easy enough to set things up so that it was indeed natural and
efficient to put each application and all it's support files all
together in the same place.  But for historical reasons that's just not
the way we do it, and it may in fact be impossible to get there from
here.
--
John Brock

 
 
 

Red Hat's RPM v. SlackWare's packages?

Post by Josh Ste » Mon, 08 Jul 1996 04:00:00



>I think what may be "inherently broken" is the basic Unix model, where
>you search for executables and other support files in a "path" of
>directories.  There is nothing inevitable about doing things this way,
>it just happened to be what made sense to the people who first designed
>Unix (or whoever they got the idea from), and since then it has been
>passed down from generation to generation, even unto the present day.
>There are many arbitrary choices that go into designing an operating
>system, and many paths that could have been taken, but weren't.

If you suggest a concrete alternative then people could critique
its advantages and disadvantages.

Quote:> I'm>sure that if someone were designing an operating system from scratch it
>would be easy enough to set things up so that it was indeed natural and
>efficient to put each application and all it's support files all
>together in the same place.  But for historical reasons that's just not
>the way we do it, and it may in fact be impossible to get there from
>here.

I would put it this way:  there is a lot of existing code and
many widely adopted standards that depend on the existing
conventions.  However, there is very little in the existing
scheme to stop anyone from writing all sorts of application
management interfaces that isolate the naive user, and perhaps
even the system administrator from micromanaging the details
of the directory layouts.  RPM seems to be a good attempt at
a move in that sort of a direction, but much more comprehensive
schemes are certainly possible.  

Notice that this general issue is not particular to Unix:
uninstaller programs for MS-Windows are frequently found
among lists of Top 10 best selling commercial software
packages and there has been an enormous brouhaha lateley
about the differences between the registry formats for
Windows 95 and NT as well as the question of how application
programs should use the registry (e.g. MS IE and Netscape
fighting to install themselves as the default browser).

- Josh

--
-------------------------------------------------------------------------------
jstern

-------------------------------------------------------------------------------

 
 
 

Red Hat's RPM v. SlackWare's packages?

Post by John Bro » Tue, 09 Jul 1996 04:00:00





>>I think what may be "inherently broken" is the basic Unix model, where
>>you search for executables and other support files in a "path" of
>>directories.  There is nothing inevitable about doing things this way,
>>it just happened to be what made sense to the people who first designed
>>Unix (or whoever they got the idea from), and since then it has been
>>passed down from generation to generation, even unto the present day.
>>There are many arbitrary choices that go into designing an operating
>>system, and many paths that could have been taken, but weren't.
>If you suggest a concrete alternative then people could critique
>its advantages and disadvantages.

I am less interested in defending particular alternatives than in
simply noting that they exist, and that the present setup was
determined as much by historical accident as anything.  The Unix file
system really is very simple.  I worked for a long time on a VM/CMS
system, and after moving to Unix I often missed having a record based
(rather than stream based) file system.  You can certainly roll your
own record based (or even indexed) files, but because it happens that
they were not there at the beginning there will never be a universal
way of doing this.  On the matter at hand, one thing that comes to mind
is the possibility of more types of special files and directories.  One
example is the special package directory in the NeXT operating system,
which looked like a single file unless you deliberately opened it up.
Another thought: why aren't the *subdirectories* of a directory that is
part of a "path" also searched for resources?  That might lead to a
whole different way of organizing things, which might (or might not) be
better than what we have (I can't pretend I've thought this through to
the point where I could answer this).

Quote:>>I'm sure that if someone were designing an operating system from scratch it
>>would be easy enough to set things up so that it was indeed natural and
>>efficient to put each application and all it's support files all
>>together in the same place.  But for historical reasons that's just not
>>the way we do it, and it may in fact be impossible to get there from
>>here.
>I would put it this way:  there is a lot of existing code and
>many widely adopted standards that depend on the existing
>conventions.  However, there is very little in the existing
>scheme to stop anyone from writing all sorts of application
>management interfaces that isolate the naive user, and perhaps
>even the system administrator from micromanaging the details
>of the directory layouts.  RPM seems to be a good attempt at
>a move in that sort of a direction, but much more comprehensive
>schemes are certainly possible.  

>Notice that this general issue is not particular to Unix:
>uninstaller programs for MS-Windows are frequently found
>among lists of Top 10 best selling commercial software
>packages and there has been an enormous brouhaha lateley
>about the differences between the registry formats for
>Windows 95 and NT as well as the question of how application
>programs should use the registry (e.g. MS IE and Netscape
>fighting to install themselves as the default browser).

But notice that DOS/Windows drew a lot of its inspiration from Unix,
and thus tends to have the same sort of problems.  I think Unix's
simplicity had a lot to do with its success, but in the end I think it
had TOO MUCH simplicity, which has lead to it's being patched up and
extended in dozens of incompatible ways.  I wish I knew more about the
IBM's AS/400 system; I get the feeling that it is a *lot* more
sophisticated, in many ways, than any of the Unixes or Unix
derivatives, and I suspect it would be an excellent example of
different paths taken to different solutions.  It would certainly be
interesting to see a point by point matchup by someone who know both
systems well.
--
John Brock

 
 
 

Red Hat's RPM v. SlackWare's packages?

Post by Josh Ste » Tue, 09 Jul 1996 04:00:00





>>>I think what may be "inherently broken" is the basic Unix model, where
>>>you search for executables and other support files in a "path" of
>>>directories.  There is nothing inevitable about doing things this way,
>>>it just happened to be what made sense to the people who first designed
>>>Unix (or whoever they got the idea from), and since then it has been
>>>passed down from generation to generation, even unto the present day.
>>>There are many arbitrary choices that go into designing an operating
>>>system, and many paths that could have been taken, but weren't.
>>If you suggest a concrete alternative then people could critique
>>its advantages and disadvantages.
>I am less interested in defending particular alternatives than in
>simply noting that they exist, and that the present setup was
>determined as much by historical accident as anything.  

Of course there are alternatives, but that's not the same thing
as saying that the Unix model is inherently broken.  If you
don't want to advocate particular alternative solutions,
perhaps you could list what you see as the primary shortcomings
of the present system.  I'm quite interested to hear to what
you have to say.  My expectation is that the shortcomings you list
will be things that can be more than adequately addressed by adding
application and account management software to the current standard
environment.  To my mind, that would indicate that the
current setup is not inherently broken.

For instance, you might legitimately complain that it is difficult
for a user to know of all the places where an application might
put relevant files: executables in /bin, /sbin, /usr/bin, /usr/local/bin, etc.
configs in ~/.***, /usr/lib/***/***, permissions in /etc/***
and so forth.  But this valid objection can be addressed by systems
that present users with uniform ways of accessing the relevant
information and manipulating various packages.  RPM seems like
a reasonable step in that direction, but it is easy to see that
a lot more can be done.

Quote:>The Unix file
>system really is very simple.  I worked for a long time on a VM/CMS
>system, and after moving to Unix I often missed having a record based
>(rather than stream based) file system.  You can certainly roll your
>own record based (or even indexed) files, but because it happens that
>they were not there at the beginning there will never be a universal
>way of doing this.  On the matter at hand, one thing that comes to mind
>is the possibility of more types of special files and directories.  One
>example is the special package directory in the NeXT operating system,
>which looked like a single file unless you deliberately opened it up.
>Another thought: why aren't the *subdirectories* of a directory that is
>part of a "path" also searched for resources?  That might lead to a
>whole different way of organizing things, which might (or might not) be
>better than what we have (I can't pretend I've thought this through to
>the point where I could answer this).

So how do any of these things that you mention expose fundamental,
or even important limitations of Unix?

Btw - one of the most basic reasons for storing configuration
data in plain ascii text files is so that, in a pinch, all of
these files can be accessed and changed with a single tool:
an ascii text editor.  This is quite critical for many
situations that arise in system administration.  Many other
types of solutions have been historically rejected for the simple
reason that they lose this property without gaining any real power
in return.  So if you want to propose differences, e.g. record
based files, then you should say what you gain by doing so
which compensates for the loss of the ascii edit-ability.

- Josh

--
-------------------------------------------------------------------------------
jstern

-------------------------------------------------------------------------------

 
 
 

Red Hat's RPM v. SlackWare's packages?

Post by Bill Newm » Wed, 10 Jul 1996 04:00:00


: >  The reason for using any packaging system (at least the reason
: >why *I* use them) is too keep track of my installed software.  Mainly to
: >ease upgrading them (since a lot of UNIX software packages tends to be
: >scattered throughout the filesystem, this make some kind of software
: >accounting system a necessity).  However, I'm wondering ... why use a
: >packaging system at all?  Why not do it like you would do it in DOS or
: >OS/2 ... install the software entirely in it's own directory.  Then when
: >you wanna upgrade the software, just delete the directory.  Or in other

: Yuck.  That stinks.  A completely installed Red Hat system would
: need 300 different directories with all of it in your path.  Yuck.
                                      ^^^^^^^^^^^^^^^^^^^^^^

Is this necessarily true?  When I build/install software on my current
system, I often leave it in a subdirectory of /usr/local/src, and use
symbolic links to connect externally-visible files (executables, man
pages, libraries..) to PATH and MANPATH and library paths.  I don't
think there's any fundamental reason this couldn't be done for most
packages.  (Note that I am almost totally ignorant of RPM, so please
don't take this post as a suggestion that this approach would be
better than RPM -- I haven't a clue!  But this approach might work
better than you think.)

  Bill Newman

 
 
 

1. can't install rpm packages - red hat 6.2

I just installed Red Hat 6.2 on my gateway pc, this is my first endevor into
Linux.  Anyhow, I can use RPM to install packages from all the red hat disks
except one - the "Powertools Applications" Disk.  When I try to install
packages from this disk, it claims to install them, but when I query the
package it says it was installed to "/", and it is nowhere to be found.
If I then select "uninstall" it complains that it can't find the files.

Has anyone else experienced this?  It's bizarre because this doesn't happen
with the other disks.

2. connect to Unix Server through modem

3. how to use RED HAT's RPMS under SlackWare?

4. LINUX Dial in help

5. Red Hat 7.1 - Installing Red Hat packages after Red Hat is already installed.

6. LILO over serial line broke?

7. rpm: not found 'packages.rpm'

8. Warnings on imap make

9. Red Hat's Linux Application CD which ships with Red Hat Professional Server Version 7

10. ? Red Hat 6.1 'apropos' don't work.

11. Installing Red Hat packages after Red Hat is already

12. Red Hat 6.2, Highpoint HPT366: installs fine, won't boot stopping at 'LI'

13. Red Hat RPM's of Xfree86 3.3.3 hangs my Linux - help.