On 4/29/07, Michael Homer <[EMAIL PROTECTED]> wrote: > Hi, > I know this has come up before, multiple times, and it never goes > anywhere.
And here we go again! :) Just kidding. I'm fully convinced we need USE flags or something equivalent (and have been for a while by now). > I have a more specific proposal, though, and I think that > implementing it would give genuine benefits, while making actual flags > possible on the way. > > As Tom pointed out on -users a few days ago, performing an Xorg > compile takes an age, and a huge amount of it is completely > unnecessary: I don't have a Cirrus video card, so compiling > XF86-Video-Cirrus is pretty pointless. I would like to have something > like VIDEO_CARDS in Gentoo, that would enable compiling just the ones > I have. That was the point of modular X, after all. (Minor nit: I suspect it was more for developer convenience than user convenience. The recent boost in X development seems to reflect this. But I digress.) > It would also obviate the need to recompile the entire thing for > updates to only a small part of it. That would also require being able > to tell which parts were already compiled and at what version, which > probably means splitting the package out and installing them all into > their own /Programs directory. I don't know whether there's a > practical problem doing that (library searching?) or whether it's not > done just to avoid cluttering /Programs with many XF86-* entries. > There would be much less of a problem with clutter under this scheme, > since most people would only have four or so of XF86-Video-* and > XF86-Input-* installed, rather than all 68. Yeah, I don't know how well Xorg works with its parts separated in /Programs -- there might be path issues to fix. Maybe an intermediate approach could be used; if my memory serves me well, we used to have Xorg metas such as Xorg-Libs, Xorg-Apps, etc. Drivers could be kept isolated but things like libs could be kept together to reduce clutter on /Programs. > All this would mean a change to the structure of meta-recipes, or > possibly dropping Xorg as a meta-recipe altogether. The changes > involved in making this happen would also allow for other sorts of > conditional dependencies and similar, which is another benefit. The > main practical and pragmatic reason for bringing this up right now > though is X, and I think it is a tangible benefit. The flow-on effects > are a bonus. > > It would be a fairly big change, and so it'd have to wait until at > least the next release cycle, but it's something worth keeping in > mind. The specifics of how to implement it I've deliberately left up > in the air, but I do have a few ideas for how it could work. I'm > interested in what comments other people have to make. My main comment is to reiterate that USE flags are welcome. I have an abstract sentiment that part of it could be automated with optional dependencies (ie, "don't build the GTK+ interface if I don't have GTK+ installed") but I don't have a concrete image of how everything would fit together implementation-wise. -- Hisham _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
