more Core dependency data
Mike A. Harris
mharris at mharris.ca
Mon Jun 26 10:34:40 UTC 2006
Jesse Keating wrote:
> On Fri, 2006-06-23 at 03:01 -0400, Mike A. Harris wrote:
>> 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.
> Why does it matter if it is in Core or Extras? How is it getting
> installed to the users system? Is it in Comps somewhere, as a default
> or required package? Or is it someting that users have to yum install
> foo after the install if they want it. If that's the case, why can't it
> live in Extras?
It is easy for the X Development team to maintain all of the
drivers that ship with X as a set, which can be updated all
at the same time, using a single consistent policy, procedure,
set of guidelines, repository, and buildsystem.
Moving things like this to Extras does not buy anything
that terribly useful, and it makes them unavailable during
OS installation. For example, do you wish to force VMware
users to install the OS via text mode, and then later yum
install the drivers from Extras and have to rerun the
config utility? That is quite foolish IMHO.
The benefits of keeping these in the distribution far outweigh
any advantages of tossing them into Extras, both to end users,
to the X Devel team, to the Fedora Community, to Red Hat, and
to VMWare Inc. who was kind enough to provide the drivers to
X.Org so that things can work out of the box during OS
installation, and post install without additional effort
being expended by users.
When we produce media that merges Core and Extras and anaconda
can install from both, without requiring network access, and
the Core and Extras repositories are merged somehow or using
identical back end infrastructure, all of the points I have
just made will be nullified.
Mike A. Harris * Open Source Advocate * http://mharris.ca
More information about the Fedora-maintainers