[MiNT] RPM

[evan@coolrunningconcepts.com]

Probably a little late to change the subject line, but I did.

Quoting jan.thomas@bt.com:
> rpm --force, see below (yes I answered this post backwards ;-)

This command ... after a really large list of dependencies that I WAS 
installing
led various instabilities.  I would not want a situation where this is needed,
nor should the user even be told it is there.  Make the front-end grab 
anything
that is dependant, and use re-linkable libraries (see Howard Chu's post about
AIX) instead of dynamic libs.

> Good idea. It will have to be a good implementation though or
> we will end up with similar problems as windows users. Plus
> youve seen how windows has "dumbed down" its users over the
> years??? ;-)

So has Gnome.

As to the implementation, I'm working on a framework that will make it 
very easy
to treat anything as a reusable component - including using the desktop
file/folder views to view any type of data, including search results.  Once
this is finished, then the above sort of interface will be simply just a new
data source for desktop.

> Peter, You mean not knowing what the name of the file is, or
> not knowing whats going on at all? I have been in that boat.
> Knowing how to use the "find" and "grep" commands helped me
> out a lot. But as Evan says, there is no substitute for good
> docs. And these days, there is such a huge *nix community on
> the net (not so in the days I was trying to learn this stuff)
> that you can get answers to anything pretty quickly with
> <insert your favourite search engine here>.

The RPM command also has a complete set of query commands that will let you do
that.  You can even open an RPM file itself and just view the contents to see
the paths and filenames and you can guess the config file pretty easily.  I
don't remember the exact commands.

Gentoo has a similar feature, and although its not RPM, I'll use it as an
example since I know the commands and use them often.

Let's say you find a file on your system.  Its corrupted, so you want to
re-install it, but you want to know what package installed it.   You 
use "qpkg"
with "-f" to find the package.  For example:

taro taro # qpkg -f `which grep`
sys-apps/grep *

And if you want to know all the files that the package

taro taro # qpkg -l sys-apps/grep
CONTENTS:
/bin
/bin/grep
/bin/egrep -> grep 1121944793
/bin/fgrep -> grep 1121944793
/usr
/usr/share
/usr/share/doc
/usr/share/doc/grep-2.5.1-r7
/usr/share/doc/grep-2.5.1-r7/README.gz
...

I won't put the whole list, but it is colorized to show directories vs files.
You can also get information like what version is installed, and what 
the latest
version available is to know if an upgrade is available.  You can also get the
part of the Changelog for the new version to see what has changed before you
upgrade.  And "emerge world" will upgrade all packages on the system for which
an upgrade is available.   A GUI wrapper around these query functions (which
most are available for RPM based systems) would give a few nice features.

> I run MiNT, and also SUSE on the PC, I have to administer Solaris
> boxes at work. They are all very much alike with subtle differences
> regarding where config files are put. I figure that SpareMiNT was
> based around the BSD system, its very reminiscent to me of SCO SVR4
> I used to work with. But I digress...

Uhmm ... the choices are BSD and SysVr4.  SCO SVR4 is System V r4, which isn't
BSD at all.  MiNT and Linux are mixtures.  Saying BSD is reminiscent of SysVr4
doesn't make sense - they are both Unix is all.

> Two-in-One is a good GUI for the command line compression tools.
> Still too much "mousing" for me though. Give me "unzip *.zip
> /putitthere" anyday.

There are GUI tools for all archivers.  The traditional "winzip" like 
interface
isn't the greatest, IMHO.   I prefer a "virtual folder" approach with a right
click option to "uncompress" in place, and the ability to drag-n-drop onto an
archive to add files to it.

> Yes, good idea. I want an icon on my desktop that opens Bash,
> just like on my SUSE box.

Well, for SUSE, this would be opening an xterm.   I'm thinking of a 
system that
would actually be a bit better than Unix systems.  On Unix if you click
/bin/bash, its not going to display in a window.  I think we can do this
safely.