Merged proto package

[Luc Verhaegen]

On Tue, Apr 06, 2010 at 11:14:18PM -0700, Keith Packard wrote:
> On Wed, 07 Apr 2010 07:38:12 +0200, Rémi Cardona <remi at gentoo.org> wrote:
> 
> > We (in gentoo) have spent a lot of time trying to figure out which
> > protos each app really needs. Now that the split has been done for so
> > long, I just don't see the advantage of merging them back.
> 
> For distros who have already done the work, the advantage is minimal,
> aside from only needing to repackage one thing when changes are made.
> 
> The people we're trying to reach with this are those people building
> From source.
> 
> For people like me, who really can't rely on a distribution to be up to
> date enough, I end up installing protocol headers. Of course, they go
> stale if I don't keep on top of them, and so I get accidental version
> skew. Reducing the number of packages I have to track from 20 to 1 would
> avoid this almost entirely.

How much work is this, really? Later on you say that there are no 
dependencies for them, so it just boils down to updating, running 
autogen.sh and make install.

It seems like this can be very easily scripted.
 
> For people who would like to try out current X server, mesa or driver
> bits, we stick them with a huge number of tiny packages to install to
> get stuff building. I was working with a hardware validation person just
> a few weeks ago; she had a list of some twenty modules required to build
> the current Intel driver and X server. 

I am sure that the proto headers are the least of this persons worry. 
What about the big dependencies, like the kernel and libdrm and then 
the forced update of mesa? Why try to tackle the non-issue first and 
avoid the real issues?

> > Or do we plan to break protos all over again?
> 
> No, we keep trying to avoid that. At least we'll catch it sooner if more
> people are up-to-date with the protocol headers?
> 
> Given that these packages all install only header files and have no
> dependencies, it's hard to see the value of breaking them up into
> separate packages.

But don't the protocol headers each have packages depending on them 
separately, so that an update of the amalgamut triggers an update of 
many of the packages above the protocol header amalgamut?

> When we did the modularization work, we split things up into the
> smallest possible units. For my part, this was probably a habit learned
> From working on tiny embedded systems. For libraries and applications, I
> think that's a good thing as those things take real space on lots of
> machines and can introduce security issues. For header files, I'm having
> a hard time seeing the value and I know it's costing the time of a lot
> of people who help with the project.

So you want the protocol headers, upon which those libraries and 
application depend, joined together, but keep the libraries and 
utilities, of which some just depend on some protocol headers and libc, 
all separate, even though a small update to any one currently 
separate proto package, will now trigger an update of all?

This does not make much sense to me.

> I don't want to merge the whole mess back together again, I think we're
> all happy to have the libraries and CLI applications live a separate
> life far from our daily activities. However, I do want to encourage
> people to develop and test stuff, and when it's reasonable, we should
> make that more convenient.

This is not the way to make it more convenient. A single big proto 
package will trigger an update of all packages which formerly depended 
on a single or a few protocol headers, which will in turn force updates 
of other packages up the stack.

You are making things a lot harder.

> In my ideal world, a user interested in trying out the latest driver
> bits for their video card would have to download two modules, the
> protocol headers and the X server/drivers. Just merging the protocol
> headers together gets us to four -- headers/server/video/evdev. Yeah,
> there are also kernel/mesa/libdrm issues, and we should figure out how
> to make that easier too.

In an ideal world, graphics drivers are slightly backwards compatible, 
so that no xserver, mesa, kernel, base libdrm updates need to happen 
(within a reasonable window that is up to the graphics driver 
developers, but you will have to be reasonable). This is not hard to 
achieve, not at all, but it is something that you have refused to occupy 
yourself with for as long as you have been doing driver development.

The proto change is a pointless change, or more accurately, it is one 
that will put us firmly on the path of re-modularization and it will 
make things a lot harder for everyone.

So, either tackle the real issue, which is that of lacking (build time) 
compatibility of both the xserver and the drivers (imagine being able to 
build an xserver that is compatible with a slightly older dri2 -- then 
you do not have to update the proto either, and you can just drop in 
the new xserver and test all the other bits of it just fine without 
changing anything else in your system), or own up to the fact that 
you're going for a full re-modularization.

Luc Verhaegen.