Merged proto package
Luc Verhaegen
libv at skynet.be
Fri Apr 9 00:45:01 PDT 2010
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.
More information about the xorg-devel
mailing list