Xserver driver merging pros & cons

[Arkadiusz Miśkiewicz]

On Thursday 15 of September 2011, Jeremy Huddleston wrote:
> On Sep 15, 2011, at 2:45 PM, Arkadiusz Miśkiewicz wrote:
> > On Thursday 15 of September 2011, Jesse Barnes wrote:
> >> At XDC this week we discussed merging drivers back into the server
> >> tree.  One thing I found frustrating about the discussion was that we
> >> didn't have a whiteboard nor a list of the pros & cons of such a
> >> change.  So I'd like to capture that here (from memory) to let us
> >> continue the discussion about whether it's worth it or not.
> > 
> > From distro package maintainer point of view I _love_ split drivers. It's
> > so much easier to packages these, rebuild when needed (one faulty, not
> > building, driver doesn't stop whole build process), easier to patch and
> > backport fixes.
> 
> I don't see how it is easier.  git-cherry-pick should do most of that for
> you just like it currently does.  You'd just be doing it in a clone of
> xorg-server rather than a clone of xf86-video-*

+ rebuilding + testing applies to "backporting". rebuilding which ends with 
rpm packaging of course.

> > Monolitic thing causes one build problem to stop building the whole
> > thing.
> 
> Hopefully integration will help find such build failures BEFORE they're
> pushed.  It also makes failure points more obvious on the tinderbox.

The problematic failures are mainly due to different non X related environment 
(like new gcc, libtool or something).

> > Also with monolitic you need to find out which files are for which
> > package (in case if you want to split that into subpackages on rpm spec
> > level for example).
> 
> I don't think that's a particularly persuasive argument.  Mask out
> /usr/lib/xorg/modules/drivers and /usr/lib/xorg/modules/input from
> installing with your master xorg-server package.  Each driver in each of
> those directories gets their own subpackage.  When new ones show up,
> they'll be excluded by your base exclusion rule until you create a new
> package.

There are manual pages, docs, sometimes utils, too. This isn't some great 
problem but it is still easier with non-monolitic way.

-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/