Michael Nielsen wrote:
Simply not true. Right this moment I'm copying podcasts to my mp3
player which was mounted directly by Gnome. It's accessible under
Try to mount an NFS/CIFS, which were what i was talking about, sorry for
being imprecise.
Appears under .gvfs? At least in Gnome. I'm still failing to understand
why this is a problem though. Even if as you're saying it's impossible
for scripts / command line programs to access shares mounted through the
GUI, then mount them the 'traditional' way. Be that via fstab,
automounter or whatever. Really, what have you lost?
>> Solaris systems amongst others, I get tired
of playing guess the location of the binary, hunt the man page and
setting an ever increasing $PATH.
Actually all the install script (for the application) was to update the
global login scripts, for the PATH variable, then the user
would see it as if the whole system was a flat directory.
Seems messy to me. I have a well loaded system, 2214 packages installed.
If as I think you're suggesting, most of these would be under /opt in
their own tree, I can just imagine the size of $PATH.
It is a big disadvantage when testing, because the current scheme
prevents having Firefox-2 and Firefox-3 (apache-1.3, apache-2.2 etc)
installed, under package management because they contain files that
conflict, similarly with 64 bit systems, where you need to install 32bit
compatability software, they usually conflict, due to irrelevant
documentation files conflicting.
It is perfectly possible to have multiple versions of a package
installed, providing it meets various requirements. Most people usually
have at least 2 kernel packages installed for example. The current
scheme doesn't prevent what you're suggesting, it just discourages it.
You are still able to install software in /opt if you wish, either from
a tarball or from an rpm. In addition, I suspect there would be a
serious lack of man power if you expected the Fedora packagers to
maintain multiple official versions of many packages.
I find it a huge problem, when there is a problem with system package,
that I need to replace with a newer version, sometimes there are files
left behind, that cause problems when you compile your own version.
RPM does a good job of cleaning up after itself. Far better than the
average human chucking tarballs over the system could. The kind of
problems you're describing, I've only ever really seen when people 'make
install' over their system files, or don't follow the logical upgrade
route. Eg, installing Foo V1 from repo A but upgrading it with Foo V2
from repo B. Sure, somebody can build a terrible RPM which is just plain
nasty but that's not the norm for Fedora, nor a fault in the
methodology. I've seen vendors package a tarball inside an RPM, which
installs everything in the %post scripts. As far as the RPM database is
concerned, all it's done is installed foo.tar.gz in /tmp.
Also you cannot with the "everything in one dir" philosophy handle the
situation where a user (or administrator) compiles a newer version from
source, and there is a version installed via the package manager..
Of course you can! Just don't install the self compiled version over the
top of the packaged version. Lookup --prefix and DESTDIR=. Users can do
the same in their home directory.
You can avoid using the GUI (which I prefer), however, what I mean is,
if you use the gui to configure the network, and you're not careful, you
can find that the configuration you performed, is tied to your GUI
account, and when you reboot, the settings are lost, until you log in
again.
Then do it from the command line, like you prefer? What's the problem?
If you're a power user, I would imagine you would know what belongs to a
user's session and what is system persistent. If you're a novice user,
then I would think you'd enjoy choosing your network from the
NetworkManager applet and would not care that your network settings were
specific to your session.
I don't like the approach of creating
parallel configurations, that are tied to the GUI.
That's the whole point! UNIX has always been a multiuser system. User's
have their configuration files and there are system wide configuration
files. Why should all users be forced to use the system default display
mode for example? Sure set a system wide default, but if one user wants
1600x1200 when they log in and another wants 1024x768, why limit it?
--
Ian Chapman.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
