Just playing with a new system install from FC5 (currently updating to rawhide), and I noticed there's a lot of xorg-x11-drivers that I don't require... is there a way to remove these? as if I just try, say, "rpm -e xorg-x11-drv-vmware" then it says that it can't be removed because it's required by xorg-x11-drivers.
The first thing I thought of was to try --force, but then I remembered that --force only works for install and upgrades of packages.
Is this possible in FC?
On Tue, 09/05/2006 11:05 +0100, Steven Haigh wrote:
Just playing with a new system install from FC5 (currently updating to rawhide), and I noticed there's a lot of xorg-x11-drivers that I don't require... is there a way to remove these? as if I just try, say, "rpm -e xorg-x11-drv-vmware" then it says that it can't be removed because it's required by xorg-x11-drivers.
The first thing I thought of was to try --force, but then I remembered that --force only works for install and upgrades of packages.
Is this possible in FC?
Fixed in FC6, I believe.
On 05/09/2006, at 9:22 PM, Leon wrote:
On Tue, 09/05/2006 11:05 +0100, Steven Haigh wrote:
Just playing with a new system install from FC5 (currently updating to rawhide), and I noticed there's a lot of xorg-x11-drivers that I don't require... is there a way to remove these? as if I just try, say, "rpm -e xorg-x11-drv-vmware" then it says that it can't be removed because it's required by xorg-x11-drivers.
The first thing I thought of was to try --force, but then I remembered that --force only works for install and upgrades of packages.
Is this possible in FC?
Fixed in FC6, I believe.
I'm just trying this in a fully updated rawhide system, and it still comes up as required by xorg-x11-drivers-7.1.3.i386
romal@gmx.de wrote:
Hi,
The first thing I thought of was to try --force, but then I remembered that --force only works for install and upgrades of packages.
rpm --erase --nodeps foobaa
should help.
No. Thats a good way to end up with broken systems. The packaging is deliberately done since we dont have a way to install drivers on demand currently. It was discussed a while back in fedora-devel list when we switched into modular Xorg.
Rahul
On Tue, 09/05/2006 13:19 +0100, Steven Haigh wrote:
On 05/09/2006, at 9:22 PM, Leon wrote:
On Tue, 09/05/2006 11:05 +0100, Steven Haigh wrote:
Just playing with a new system install from FC5 (currently updating to rawhide), and I noticed there's a lot of xorg-x11-drivers that I
don't require... is there a way to remove these? as if I just try, say, "rpm -e xorg-x11-drv-vmware" then it says that it can't be removed because it's required by xorg-x11-drivers.
The first thing I thought of was to try --force, but then I remembered that --force only works for install and upgrades of packages.
Is this possible in FC?
Fixed in FC6, I believe.
I'm just trying this in a fully updated rawhide system, and it still comes up as required by xorg-x11-drivers-7.1.3.i386
-- Steven Haigh
Email: netwiz@crc.id.au Web: http://www.crc.id.au Phone: (03) 9017 0597 - 0412 935 897
I only have the following xorg packages installed:
xorg-x11-server-utils-7.1-4.fc6 xorg-x11-fonts-base-7.1-2 xorg-x11-drv-mouse-1.1.1-1.1 xorg-x11-xauth-1.0.1-2.1 xorg-x11-apps-7.1-2.fc6 xorg-x11-xkb-utils-1.0.2-2.1 xorg-x11-font-utils-7.1-2 xorg-x11-xfs-1.0.2-3.1 xorg-x11-drv-keyboard-1.1.0-2.1 xorg-x11-drv-vesa-1.2.1-2 xorg-x11-drv-evdev-1.1.2-2.1 xorg-x11-xinit-1.0.2-9.fc6 xorg-x11-filesystem-7.1-2.fc6 xorg-x11-utils-7.1-2.fc6 xorg-x11-drv-void-1.1.0-3.1 xorg-x11-server-Xorg-1.1.1-34.fc6 xorg-x11-drv-nv-1.2.0-4.fc6
My FC6 is happily running gnome-2-16.
On 9/5/06, Steven Haigh netwiz@crc.id.au wrote:
Just playing with a new system install from FC5 (currently updating to rawhide), and I noticed there's a lot of xorg-x11-drivers that I don't require... is there a way to remove these? as if I just try, say, "rpm -e xorg-x11-drv-vmware" then it says that it can't be removed because it's required by xorg-x11-drivers.
The first thing I thought of was to try --force, but then I remembered that --force only works for install and upgrades of packages.
Is this possible in FC?
I don't think it is a good idea, distribution-wise. If you ever upgade your graphic card, you will get a non-working system.
On Tuesday 05 September 2006 09:02, Pasha R wrote:
I don't think it is a good idea, distribution-wise. If you ever upgade your graphic card, you will get a non-working system.
Then I wonder what the point was to splitting them up? I was one who thought this would be a great time to jettison all the old video card drivers. Like when would you ever install a Tseng video card? Or S3? And if you did, won't the Vesa drivers work well enough until you install a more optimized driver?
-Steve
On Tue, 2006-09-05 at 09:36 -0400, Steve Grubb wrote:
Then I wonder what the point was to splitting them up? I was one who thought this would be a great time to jettison all the old video card drivers. Like when would you ever install a Tseng video card? Or S3? And if you did, won't the Vesa drivers work well enough until you install a more optimized driver?
Now when an update is made to an upstream driver, the X maintainer just has to respin the driver, not the entire Xorg blob. An update can be made just for the driver package which is a MUCH smaller download than the entire Xorg blob. If in the future we get some way of doing dynamic package loading based on hardware detection, then we can trim out the packages.
On 05/09/2006, at 11:41 PM, Jesse Keating wrote:
On Tue, 2006-09-05 at 09:36 -0400, Steve Grubb wrote:
Then I wonder what the point was to splitting them up? I was one who thought this would be a great time to jettison all the old video card drivers. Like when would you ever install a Tseng video card? Or S3? And if you did, won't the Vesa drivers work well enough until you install a more optimized driver?
Now when an update is made to an upstream driver, the X maintainer just has to respin the driver, not the entire Xorg blob. An update can be made just for the driver package which is a MUCH smaller download than the entire Xorg blob. If in the future we get some way of doing dynamic package loading based on hardware detection, then we can trim out the packages.
I understand the reasons for going modular, and I love the idea. I guess the big question in my mind is why do I care if the s3 driver or vmware driver has a security hole and needs an update? Sure, I won't be using it - ever - which means it can have all the holes in there it likes, it will never get run. Keeping this in mind, why would I want to bother downloading updates for X drivers that I don't have?
Even at worst case, and I did pull my laptop apart, desoldered the video chips and upgraded the card (or simply replaced the card in a desktop :)), then hopefully I'd know that I can install the latest driver via yum from a console (even if X completely refused to work!).
Following this even further, even if I didn't know what graphics card drivers are out there, I could use 'yum list xorg-x11-drv*' to get a list and go from there.
Maybe this is best dealt with in the installer - as it already setup up X to work after the installation, it could easily know what video driver to install and choose not to install the rest.
I guess I just see it as another 58 or so packages I don't have to worry about or see or update.
Steven Haigh wrote:
On 05/09/2006, at 11:41 PM, Jesse Keating wrote:
On Tue, 2006-09-05 at 09:36 -0400, Steve Grubb wrote:
Then I wonder what the point was to splitting them up? I was one who thought this would be a great time to jettison all the old video card drivers. Like when would you ever install a Tseng video card? Or S3? And if you did, won't the Vesa drivers work well enough until you install a more optimized driver?
Now when an update is made to an upstream driver, the X maintainer just has to respin the driver, not the entire Xorg blob. An update can be made just for the driver package which is a MUCH smaller download than the entire Xorg blob. If in the future we get some way of doing dynamic package loading based on hardware detection, then we can trim out the packages.
I understand the reasons for going modular, and I love the idea. I guess the big question in my mind is why do I care if the s3 driver or vmware driver has a security hole and needs an update? Sure, I won't be using it - ever - which means it can have all the holes in there it likes, it will never get run. Keeping this in mind, why would I want to bother downloading updates for X drivers that I don't have?
This is the reason we need to handle this better but we can do so without getting the ability to install drivers on demand which we dont have currently.
Even at worst case, and I did pull my laptop apart, desoldered the video chips and upgraded the card (or simply replaced the card in a desktop :)), then hopefully I'd know that I can install the latest driver via yum from a console (even if X completely refused to work!).
Following this even further, even if I didn't know what graphics card drivers are out there, I could use 'yum list xorg-x11-drv*' to get a list and go from there.
We cant expect everybody to know the names of the drivers and install them manually.
Maybe this is best dealt with in the installer - as it already setup up X to work after the installation, it could easily know what video driver to install and choose not to install the rest.
I guess I just see it as another 58 or so packages I don't have to worry about or see or update.
You can force remove packages by ignoring the dependencies if this bothers you but that is not recommended at all.
Rahul
Steve Grubb wrote:
On Tuesday 05 September 2006 09:02, Pasha R wrote:
I don't think it is a good idea, distribution-wise. If you ever upgade your graphic card, you will get a non-working system.
Then I wonder what the point was to splitting them up? I was one who thought this would be a great time to jettison all the old video card drivers. Like when would you ever install a Tseng video card? Or S3? And if you did, won't the Vesa drivers work well enough until you install a more optimized driver?
-Steve
We have already had this conversation in fedora-devel list before. It makes sense to split it up because it saves time in building the packages and releasing it independently when there is a security bug in one of the drivers for example.
In the future, if we have the ability to install drivers on demand, the packaging might be changed but it might not be worth the pain (put a disc or setup a network) for a short amount of space saving.
Rahul
Rahul wrote:
Steve Grubb wrote:
On Tuesday 05 September 2006 09:02, Pasha R wrote:
I don't think it is a good idea, distribution-wise. If you ever upgade your graphic card, you will get a non-working system.
Then I wonder what the point was to splitting them up? I was one who thought this would be a great time to jettison all the old video card drivers. Like when would you ever install a Tseng video card? Or S3? And if you did, won't the Vesa drivers work well enough until you install a more optimized driver?
-Steve
We have already had this conversation in fedora-devel list before. It makes sense to split it up because it saves time in building the packages and releasing it independently when there is a security bug in one of the drivers for example.
In the future, if we have the ability to install drivers on demand, the packaging might be changed but it might not be worth the pain (put a disc or setup a network) for a short amount of space saving.
but this should also work if a user don't have a internet connection (asking for a cd/dvd or anything like this)
Rahul
dragoran wrote:
In the future, if we have the ability to install drivers on demand, the packaging might be changed but it might not be worth the pain (put a disc or setup a network) for a short amount of space saving.
but this should also work if a user don't have a internet connection (asking for a cd/dvd or anything like this)
I already mentioned that we need to handle discs above.
Rahul
Ps: Trim your quotes.
Steve Grubb wrote:
On Tuesday 05 September 2006 09:02, Pasha R wrote:
I don't think it is a good idea, distribution-wise. If you ever upgade your graphic card, you will get a non-working system.
Then I wonder what the point was to splitting them up? I was one who thought this would be a great time to jettison all the old video card drivers. Like when would you ever install a Tseng video card? Or S3? And if you did, won't the Vesa drivers work well enough until you install a more optimized driver?
The point of splitting them up, was to allow individual drivers to be updated alone, to make maintenance of the driver packages simpler. It was also to minimize the disk space usage on FTP servers and mirror sites and network bandwidth usage consumed on those sites, and on RHN et al. when a single driver needs to be updated.
To be very clear, never at any point in the decision to have individual driver rpms, was it to allow people to uninstall drivers they didn't want or need (or didn't think they wanted or needed), nor was it to reduce or enable the user to reduce the amount of disk space used by an OS installation.
The total disk space used by all X drivers combined is extremely small, both in terms of megabytes, and in terms of dollars of disk space. Small enough on the scale of care, to be totally negligible.
On Tue, Sep 05, 2006 at 04:42:19PM -0400, Mike A. Harris wrote:
The total disk space used by all X drivers combined is extremely small, both in terms of megabytes, and in terms of dollars of disk space. Small enough on the scale of care, to be totally negligible.
That is a value judgement. It may well be accurate for us folks in North America or Europe. However, it may not be accurate for someone struggling in a non-profit, or for someone in Africa or Asia.
This sort of decision, across a lot of packages, has lead to Fedora bloat, making it less attractive to people on tight budgets. For another example, do we really need CD writing software in order to run gnome? Well, not if the machine doesn't have a CD burner.
To paraphrase Lyndon Johnson, a megabyte here, a megabyte there, pretty soon it adds up.
What we need is a generic dummy application. It pops up, or prints to stdout, as appropriate, something like, "Sorry but %s is not installed. Please install it, as root, like so: 'yum install %s'. Thank you." where %s is the name of the app the user wanted.
On Tue, Sep 05, 2006 at 04:43:30PM -0600, Charles Curley wrote:
That is a value judgement. It may well be accurate for us folks in North America or Europe. However, it may not be accurate for someone struggling in a non-profit, or for someone in Africa or Asia.
It used to be one package so its an improvement already. It will save update bandwidth and in the future can get better
What we need is a generic dummy application. It pops up, or prints to stdout, as appropriate, something like, "Sorry but %s is not installed. Please install it, as root, like so: 'yum install %s'. Thank you." where %s is the name of the app the user wanted.
You can probably do that with the current infrastructure. Pull the yum package headers, parse for /usr/bin /usr/sbin etc paths for executables and ln -s them all to a python app which can do X or command line.
Little project for someone perhaps
Alan
Charles Curley wrote:
One of the most annoying things regarding Windows is having to hunt for the install disk whenever you changed any simple item on the system. (W98 at least) The beauty with Linux is that you put in some hardware and it is relatively easy to be up and running without needing to hunt all over the Internet or install media for the appropriate drivers for the hardware. It is great for the system to be loaded as it is now. If it was decided to slim down the unused elements until needed, compressing the elements like is done for documentation would be a better concept in my opinion. I recently installed FC4 on a computer and all of the hardware worked on initial setup. Everything still worked after upgrading the system to FC5. (Except for a minor configuration file). In comparison, I installed W2K on the same system and it did not recognize the modem, sound card, video card on install. I had to install a known to work network card, hunt the Internet for specific drivers which were provided for the particular motherboard in order to get the other hardware to work. Way off the basic topic I realize. In cases regarding video cards, I change from one card to another video card frequently. Having all the drivers available and only needing to change the configuration file or allow hardware detection to make the needed adjustments is a plus and not a waste of space. People install the Fedora Distribution on one computer and swap the disk into other computers for its intended use. It works easily with the current way that most devices are ready to go with minor changes. One individuals bloat is an asset for other goals people intend to use a system for. Why complain about the drivers being there? You could probably remove the package that pulls in the requires for all of the video driver packages. Then you can customize your system to be one video driver centric. Before the hub package, I had to manually hunt and yum in different drivers for each system that I ran it on. Who needs that! (yumming or rpm installation)
Jim
Charles Curley wrote:
On Tue, Sep 05, 2006 at 04:42:19PM -0400, Mike A. Harris wrote:
The total disk space used by all X drivers combined is extremely small, both in terms of megabytes, and in terms of dollars of disk space. Small enough on the scale of care, to be totally negligible.
That is a value judgement. It may well be accurate for us folks in North America or Europe. However, it may not be accurate for someone struggling in a non-profit, or for someone in Africa or Asia.
My point is that installed system disk-space usage of the video and input drivers was not part of the deciding factor that went into choosing to modularize the drivers - regardless of wether or not somebody out there might have some benefit of not installing all of the drivers.
I've stated this only because some people might mistakenly be of the opinion that the modularization of X was done to make it possible to reduce the space used by drivers on an installed system, and that very much was not the case.
On Tuesday 05 September 2006 18:43, Charles Curley wrote:
That is a value judgement. It may well be accurate for us folks in North America or Europe. However, it may not be accurate for someone struggling in a non-profit, or for someone in Africa or Asia.
This sort of decision, across a lot of packages, has lead to Fedora bloat, making it less attractive to people on tight budgets. For another example, do we really need CD writing software in order to run gnome? Well, not if the machine doesn't have a CD burner.
To paraphrase Lyndon Johnson, a megabyte here, a megabyte there, pretty soon it adds up.
Think of modular X along the same lines as the kernel modules. You may get a kernel update because of a problem in some module that you may not be using, but we package all the modules up in one package set. Separating them all out does NOT make sense, whereas it does for Xorg. If you're building for extremely tight places, you're probably rebuilding the kernel and only bringing in the modules you need. Do the same for X.
Steven Haigh wrote:
Just playing with a new system install from FC5 (currently updating to rawhide), and I noticed there's a lot of xorg-x11-drivers that I don't require... is there a way to remove these? as if I just try, say, "rpm -e xorg-x11-drv-vmware" then it says that it can't be removed because it's required by xorg-x11-drivers.
The first thing I thought of was to try --force, but then I remembered that --force only works for install and upgrades of packages.
Is this possible in FC?
--Steven Haigh
Email: netwiz@crc.id.au Web: http://www.crc.id.au Phone: (03) 9017 0597 - 0412 935 897
--fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe:https://www.redhat.com/mailman/listinfo/fedora-test-list
This behavior is by design IRC. The thinking is that it's better to have all the drivers you need on the system just in case you happen to change out you video card. Also, the footprint of these packages is small.
Demond
-
Alan Cox -
Charles Curley -
Demond James -
dragoran -
Jesse Keating -
Jim Cornette -
Leo -
Mike A. Harris -
Pasha R -
Rahul Sundaram -
Robert M. Albrecht -
Steve Grubb -
Steven Haigh