Re: [MiNT] Re[2]: GEM boost

[<jan.thomas@bt.com>]

evan@coolrunningconcepts.com wrote:
 
> I never meant that RPMs causes dynamic lib dependancies, only 
> that RPM wasn't
> the greatest way to deal with them.  The problem seems to be 
> that many RPMs
> have an exact version of a library as the dependency.  That 
> may have been
> improved.   Hopefully, the method proposed by Howard Chu will 
> take care of
> library dependencies, and I'll be much happier.

rpm --force, see below (yes I answered this post backwards ;-)

> What if things were installed, via RPM, to a Unix-like 
> structure, but the
> desktop could give a "virtual" view of the package?   This is 
> part of a 
> desktop
> idea I have where data sources and data views are seperate 
> and abtract.
> 
> For example, you could have a virtual folder for "Packages", 
> inside is folders
> of all the RPMs you have installed.  You can drag them to the desktop 
> to make a
> link if you like.  You can also open the folder to see the 
> files that were
> installed (not nested into any tree structure, just together 
> like a GEM app
> would show them), and drag any of those to the desktop to 
> make a shortcut.
> Dragging the whole folder for that package to the trash 
> should perform an "rpm
> -e" to remove it, and dragging a new RPM into your virtual 
> "packages" folder
> could do an install/upgrade as appropriate.

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??? ;-)

> >> Also, I hate playing "hunt the file" when some config file 
> has to be
> >> edited.

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>.

> Or one that is well set up.   User configuration files go to 
> the user's HOME
> directory.  System configuration into /etc, and ... assuming 
> you are are a
> Gentoo fan, start-up configuration in /etc/conf.d ... which 
> includes most of
> your common configuration settings that are set during boot 
> and all services
> that can start on boot.  The idea is that you never have to 
> edit anything in
> /etc/init.d .. your information is in /etc/conf.d

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...

> >> I had no previous experience of package managers like RPM. 
> tar.gz was
> >> annoying enough since I couldn't use nice friendly GEM 
> progs like TWo-in
> >> One.

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 plenty of GUI RPM package managers.   Usually built 
> into the 
> desktop.
> Right click an RPM and choose "Install" or "Upgrade".

There are on linux and even windows boxes. What about MiNT? 
BTW, I have RPM explorer on my W2K but it wont open Sparemint 
RPMs...

> What if the CLI automatically popped up when you need it?  
> For example, 
> instead
> of running TOSWIN, and then having it run bash, you run BASH, 
> and the window
> appears when the program tries to output to the console?  
> Would that be
> slightly easier?
 
Yes, good idea. I want an icon on my desktop that opens Bash, 
just like on my SUSE box.

> complaint that some dependancy isn't met is annoying.

I guess that not all programmers know exactly what is provided by a particular
package, so they just set a dependency for "this package version or greater" 
that they had on their system when they compiled and tested the app. If you know
that an earlier package will provide whats needed then an RPM -Uvh --force is what
you do.

Jan.