Bill Nottingham wrote:
The following packages: - have no dependencies in Core - are not in comps - are not subpackages of something in comps Hence, the question is - should they stay in core? Should they get added to comps? Should they move to Extras? (Note that only two of these actually have deps in Extras, as well...)
[SNIP]
isicom
At one point Red Hat had a contract with the company that produced this hardware, to include the software for a certain number of OS releases, or something like that. I don't remember the details as it was like 5 years ago. I do believe though that we've more than met our obligations years ago, and I'm pretty sure there is no longer any obligation to continue shipping this software. I'm not even sure if it even still works under current kernels, etc. I think we should probably just drop it completely, and if someone complains, we can always reconsider whether to add it back to Core, or to give them the opportunity to maintain it in Extras.
xorg-x11-drv-tek4957
There are people out there who use this still believe it or not. We previously had removed it, and I either got a bug report or email beating us to a pulp for removing it. We also removed tek support from xterm at the same time and had to restore it to make some people happy. Since this type of thing just more or less "works" it doesn't require any upstream maintenance, and we'll probably not ever have to perform any maintenance on it, so it is very low impact staying in core. It is actually trivial to update it in core if it is ever updated upstream, so I believe it is best to leave it in Core.
xorg-x11-drv-vmmouse
This driver was just added recently for VMware, and should remain in Core and in future RHEL releases as well, in order to be able to optimally install the OS inside VMware, and to run X inside VMware post-install out of the box.
xorg-x11-xdm
xdm can move to Extras or stay in Core, doesn't matter much to me, and I don't think it matters much to anyone else on the X devel team per se. either. Having said that, I'd be surprised if there isn't anyone out there with a lab of machines or similar who for whatever ungodly reason chooses/prefers to use xdm and needs it to be available out of the box on Fedora installations. In the days of monolithic X, security holes were frequently found in xdm, as were various other nasty issues, and we had to update it quite frequently, which was more work than it should be due to the monolithicity of X as a whole. Nowadays however, xdm has matured quite a bit and security vulnerabilities are fewer and further between. Also, it is rather simple to patch up the modular package to fix issues, and to generally perform any maintenance that is necessary over time. A more important reason to keep it in Core however, is that it contains various config files and scripts which are also shared with gdm and kdm. We could split those files into yet another package, but then we have to manually resync them with upstream xdm any time upstream changes them - which creates more work for no real big gains. So, I'd vote to just leave xdm in Core, at least for the time being, as it's more effort to remove it from Core and clean up the mess IMHO.
xorg-x11-xfwp
To be honest, I'd be surprised if anyone even uses this at all, or if anyone ever has for that matter. I'd be perfectly comfortable seeing this dropped from Core and made available to an enthusiastic Fedora Extras volunteer. We dropped a number of apps that are provided by the X11 distribution in FC5 and for the most part, nobody has even noticed - indicating a lot of them (most of which used to be part of X11R6-contrib ages ago) are not really critical to the Core OS, and thus might make more sense in Fedora Extras if suitable volunteership is interested in taking it to task. Sorry for not responding to this previously, but I haven't read the list for a while and just went through some old mails. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian.
