More modularization.

[Mike A. Harris]

Peter Lemenkov wrote:
> On Sat, 19 Nov 2005, Mike A. Harris wrote:
> 
>>> All we need is to properly patch SPEC-file.
> 
> 
>> In short: No. Absolutely not.  ;o)
>> For the longer version, please reread my first email.  As I stated
>> therein, this is not due to it being technically impossible to do.
>> It is a concious and intentional choice that all Mesa drivers are
>> provided in one package right now, and I plan on keeping it that way
>> at least until all of the items I outlined in the first email are
>> met.
> 
> 
> Look. I haven't any of old, good videocard listed in mesa-libGL package.
> So why I haven't a way to properly strip down the package, instead of 
> manually remove never used dri-modules?

The src.rpm is available, and can be customized as desired of course.


> I don't concern a way of maintaining the source of Mesa (in one package, 
> in two packages, even in one tarball per file), I do concern the result 
> of building from %{_tmppath}/%{name}-%{version}-%{release}-buildroot. 
> After the successful compilation mesa packs into a number of packages, 
> so why just don't increase its number? :)
> 
> If someone rejects installing of particular dri-modules, everything will 
> be OK, 'cause if user don't have some mesa-dri-supported videocard, the 
> apropriate *.so-module wouldn't be used. So why take care?
> 
> Ok, maybe it's a kinda of religion/ideology to keep *all* modules 
> simultaneously?

As stated twice now, this is done intentionally to ensure that all
drivers are always installed on all systems, in order to ensure that
they are present and avoid support calls and bug reports due to missing
drivers.

Some users out there are more on the ball than others, and are capable
of uninstalling things, and knowing if and when they might need to
reinstall them, and how to go find them.  Other users may not be so
gifted, and if they have the option to uninstall things that they
"think" they do not want or need, for _whatever_ reason, they may do
so, and later find themselves in a bind.  If we allowed individual
drivers to be uninstalled, then we _WOULD_ get bug reports and RHN
customer support requests from people who have uninstalled (or not
installed to begin with) the drivers for their card.  This might
not be the card the OS was originally installed with, but rather some
board that was bought as a replacement.

ie: Install OS on a system with an Intel onboard, but don't install
anything but Intel video to "save space because I don't need it".
4 months later, purchase a Radeon 9200, and install it, then file
a bug report in bugzilla claiming you can't get 3D to work at all.

This is a "support" problem that I am not willing to endure.  The
OS has always shipped and installed _all_ video drivers forever, and
now more than ever, drive space is cheap.  There is not very much
to be gained by removing drivers that might not be needed, except
for a very small number of free megabytes.  There are a lot of
_problems_ to be gained by permitting people to uninstall individual
drivers on a whim in the land of technical support.

If you really want to remove unneeded drivers, delete them with "rm",
and you'll free up a couple megabytes.  RPM upgrades will still work,
and I can close bug reports with "I just verified the package we
shipped, contained that driver, NOTABUG".  This makes it a very
explicit action, that by removing it, you are entering into the
dark land of "not supported".

I've talked with some upstream Mesa developers since this thread
started, and it seems very unlikely that Mesa will be implementing
the items I mentioned in previous posts any time soon.  The
Mesa modules in a sense are like the kernel - they do not have a
stable module ABI that has compatibility with newer or older Mesa
releases.  This means that the Mesa modules must be used with the
exact specific Mesa release they were shipped with.  That is another
reason why the Mesa modules will remain in one single src.rpm
in Fedora Core.

The bottom line is:  Disk space is cheap.  Saving negligible space
at the expense of technical support nightmares is not a reasonable
solution.

Feel free to disagree, but there are really much more important
matters we should be spending our attention on right now.