more Core dependency data

Mike A. Harris mharris at
Fri Jun 23 07:01:03 UTC 2006

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

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  *
                       Proud Canadian.

More information about the Fedora-maintainers mailing list