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

SEUL: Re: Installation script

winston@atlantic.net wrote:
>I have been playing around with a script that will handle
>installation/maintenance of programs.
>At the moment the script only works with tarrball files (i.e. tar, tgz,
>Anyway, here is THE BEGINNING script, it uses bash.  Give it a try and
>let me know what
>you think.

seems what SLIM (greg's program) is intended to do is serve as a basic wrapper
for any flavor of package installation/maintenance, which delegates to the
full programs (rpm, dpkg, tar, etc) to do the grunge once it has indentified
the package type and queried the user appropriately as to the details of
i think this is a good sort of utility to have.

something you may consider doing also is adding in hooks for logging installs:
rpm/deb would have null procs here, since the rpm/dpkg programs do that, but
tar,etc could have support added to do the same sort of thing -- thus when a
year later you find some files on your machine and wonder what they are, you
can query SLIM about the file, and it will find its installation entry and
tell you when you installed it from what tarball.  then you can tell SLIM to
find all files associated with it, for example, or erase all files from the
package (uninstall it).  basically SLIM could enable any file utility to
have full install/log/uninstall capability.  note though the reason i say
explicitly to put in hooks for this (and not necessarily even code the
functionality), b/c there are MANY impl's that come to mind:
 o just log to a text file (create our own crude format - simple but bad)
 o use gdbm or msql as a database, so we still hack our own format, but it's
   more efficient.  (better, but much more work)
 o reuse the db scheme of whatever pkg manager is installed on the system.
   i don't know about debian, but rpm has a library rpmlib for interfacing
   to and coding to the rpm database.  i expect if this is well done, it
   could be used to merge extra entries of type seul-tarball into the main
   db, or at the very least create a separate seul pkg db, and put our stuff
   in that, but reusing a few years of work that has already put into
   creating that pkg db system.  (this is clearly a good idea in concept,
   but it needs to simply be tried to see if it will actually work -- and it
   might flop, in which case we fall back to a different strategy).
 o something else?  e.g. if seul-dev-admin does sucessfully grow into the
   highly ambitious beast that i was originally hoping for (hey, it might
   happen), then someone will be writing a seul-specific system for
   dealing with package/file registry, and we'll want to hook it in here.

i'm taking a closer look at the script now and will send you more detailed
comments shortly, greg.

>While creating this script I looked into RPM and DEB packages to attempt
>to figure out
>how the dependentcies were worked out and the nearest I could tell is
>that they aren't.
>Apparently what happens is the author of the program has to include the
>depends when building
>the RPM/DEB package.  If anyone has given this aspect any thought let me
>know what your
>findings were.

well, sort of.  the way to build an rpm at least (i don't know about dpkg yet)
is pretty conducive to including the right dependencies if you think about it
when you're building the rpm.  it is trivially possible to ignore it though.
and hence the reason we were complaining a while back about the heaps of
broken rpms around that just plain don't include correct dep info.
unfortunately, i can't think of an obvious good way to fix this.  i have the
impression that debian developers (historically) have been better about
writing their package dep info correctly, but i think that's merely an effect
of the package developers' efforts, not any builtin mechanism for enforcing
correct dependencies.  has anyone seen a system (or plans for one) that does
try to do this sort of correct dep-info enforcement?
we should give this some thought, so anyone with some clever insights....?

 Peter Luka            ...            luka@mit.edu
 SEUL Project development leader/systems architect