[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: X Strike Force X.Org X11 SVN commit: r956 - in branches/modular/driver/xf86-video-ati: . debian



On Tue, Dec 20, 2005 at 07:11:14PM +0100, David Martínez Moreno wrote:
> El martes, 20 de diciembre de 2005 18:57, Michel Dänzer escribió:
> > > 	Then we will start to receive bug reports by users without the right
> > > driver, isn't it? Probably a massive drivers-all metapackage will be a
> > > mid-term solution...
> >
> > Why only mid-term? Something like xserver-xorg depending on
> > xorg-video-drivers | xorg-video-driver (with every video driver package
> > providing xorg-video-driver and xorg-video-drivers being the metapackage
> > depending on all of them) seems like a pretty good solution to me. The
> > same principle should work with the other classes of drivers as well.
> 
> 	You are right, it seems a great solution; even simpler, xserver-xorg should 
> depend on xorg-video-driver (and xorg-video-drivers-all providing 
> xorg-video-driver in order to be show up as an alternative to the individual 
> drivers).

I think the rationale for using the metapackage | virtual package is that
apt needs a default solution to install. This way, it'll install the
metapackage by default if you choose to install the server. However, the
server will install just fine if you remove the metapackage and install an
individual driver instead. Michel's got the right solution here. That said,
I definitely like your xorg-video-drivers-all as a name for the
metapackage, since it'll be fairly obvious about what it is. 

I'll implement this scheme tonight in the server and the drivers. Since
there's no canonical home for the driver metapackage really, there's two
options for it:

 1) The server package. The rationale for this is that the drivers are all
    inherently tied to the server. The disadvantage is that the metapackage
    is a Debian-specific invention and that to update it we'll have to
    update the server itself, which is already carrying around a lot of
    weight. We may not have to update the metapackage much, but updating
    the server just to get this stinks of the monolith :-)

 2) One of the debian-specific packages, such as xorg-common or x11-common.
    The rationale for this is that the metapackage is really
    debian-specific, and updating these packages is utterly trivial, since
    they don't contain real code. The disadvantage is that the drivers
    aren't tied to either of these packages as much as the server, so it's
    not as intuitive that it should live here. I can also make a third
    Debian-specific metapackage called xorg-debian, which will include all
    the metapackages and other such distro-specific items. 
    
I'll probably go with this last option (xorg-debian) since it seems to
satisfy all my criteria, even if it bloats things by one more package. If
anyone has a preference on where the metapackage should be kept, I'd love
to hear it.

 - David Nusinow



Reply to: