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

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

OK - I've heard both sides of this, and been on both sides, so let me take a
stand one way or the other ...

Quoting Maurits van de Kamp <maurits@bassment.nu>:

Very :o) Survival of the Atari world will depend on MagiC users switching to
MiNT (being the only living Atari OS). :o)


That's an interesting statement.  It may quite well be true.


I used to think the same but I've learned that once you get used to the Unix
idea, it's much more organised. In the "old" way you have all your documents
scattered as well by the way (each in the folder of the corresponding
application). There are apps where it's really more convenient to stuff them
all in their own folder, that's what /opt is generally used for
(like /opt/netscape).


Well, netscape is kinda old, and mozilla doesn't organize things that way.
Honestly, /usr is for "vendor" stuff, while /usr/local is for "additions", such as GNU tools, and /opt is for "optional packages". Exactly what this means has been debated quite frequently. Honestly, I wouldn't care if there never was an /opt. However, I do have an /opt/fdo - for the freedesktop.org Xserver, since having it elsewhere could confuse the libraries and binaries of the freedesktop embedded X server with the primary Xorg xserver. Java stuff also winds up here 
since you can have different installations that might conflict.   The idea of
"if its optional, and it conflicts", then it goes there.
For Linux, the distributor supplied stuff (like RPMs) install to /usr and stuff 
you compile from source goes to /usr/local.  Basically this prevents
user-compiled apps from creating an unknown system state in /usr.
Yes that's kinda like Evan's arguments but that's like not going to the doctor 

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.


because you're afraid you might have a scary disease. :o) A package manager
doesn't make it more difficult to delete an application. It helps you when it
IS more difficult, and with modern apps it usually is. Modern computer use


I agree here.   If the program can't be a simple executable on its own, then
make it an RPM.  Its better than nothing.


requires applications working together and installing/removing an application
simply isn't as easy as copying or deleting a folder (file associations,
OLGA, 3rd party tools, help system integration etc etc etc).


Where is there English documentation on OLGA?   Is it MP safe?


And when you really think of it, and you compare 2 systems, one with
executables scattered all over one disk (in the corresponding application's
folders), where you have the freedom to move everything around (why?!) and


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.

Basically, the RPM installer would provide a simple way to view and query the
RPM database, show things the way Atari users expect, and allow people to see
all the files a package installed at once, or query the database to ask it
which package installed a particular file.


you'll need to reconfigure every program you have; with a unix file structure
that's just a matter of some links ("mount points" but in MiNT they're just
links) and no application will actually see the difference.
Does ext2 on MiNT have real mount points? Having to mount everything to U: and 
then symlink it seems like a pain.


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


That's why you need proper documentation. In any system.


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


I agree a graphical frontend would be nice but I do feel people are much too
religiously against CLI. In Linux I have a graphical frontend for RPM but I
never use it, since just typing rpm -Uvh (followed by the first few letters
of the name and then hitting TAB) is so much faster.
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?

Assuming of course, that RPM installation was as I outlined above.


I never know if I should be doing Install or Update !
Install is for new packages and update for new versions of installed packages, 
but update will automatically switch to install if the package wasn't
installed already, so just always do update.
I believe there was some difference in how configuration files are handled. And install installs a fresh config file and update doesn't, and there may be other 
differences in what scripts are run.   However, you are likely correct in that
if you update a package that doesn't exist, it just updates it.  However, the
complaint that some dependancy isn't met is annoying.

Any end-user interface for RPM should be capable of finding dependant RPMs on
your drive or the internet and downloading them for you and installing them
automatically.  Something like yum.

-- Evan