On 5/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > 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.) And that too. > > > 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. I have tried it with a few drivers - it seems to work ok. It's possible some of the core libraries need to go together, I guess, I didn't examine them. Joining the core and libraries together isn't such a bad idea all the same, although it will prevent updating single components on their own. I don't know how often that occurs, but it's not that uncommon for the drivers. > > 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. That would be useful too - but it doesn't help for hardware-required programs (unless you examine /proc/config.gz really closely, and that's likely to be difficult to do flawlessly).
One component of my original idea was to have installed programs automatically become enabled flags, which would have that effect. There would still need to be another, parallel system to deal with the other situations, and a way to disable the flags created this way. I don't know whether that would be more trouble than it's worth; it might be confusing to have behaviour changes because of an unrelated install. It might also be necessary to allow per-program flags (as in, "enable the GTK+ interface to Foo, but don't build the Qt one, even thought I have both installed"). I don't know how would be best to go about that. Gentoo uses text files; we might prefer a filesystem-based approach. I would quite like to have some way to find out which programs were compiled with which flags, in both directions. That could be symlinks, I'm not sure whether it'd ever actually be useful to traverse a tree like that. Post-014 I would like to put some work into getting something like this up and running; the specifics of which method would be best I don't know. My original idea had dependency files like `Flag_On i810 && require XF86-Video-i810 1.7.4`, and similar functions for adding configure parameters in the recipes, but I think that might get a little ugly for something complicated. It's probably necessary on the recipes' side, since things could get arbitrarily complicated there. I also don't know how this would interplay with binary packages. So really there's a lot of things I don't know yet. But I am sure that it has to happen somehow. That's why I solicited input. -Michael _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
