On 5/3/07, Michael Homer <[EMAIL PROTECTED]> wrote:
> On 5/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > 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.
Good to know.
> > > 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).
I didn't think about going this far; I agree it's probably not worth the effort.
> One component of my original idea was to have installed programs
> automatically become enabled flags, which would have that effect.
That's basically what I had in mind too.
> 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.
Right.
> 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
A flag to compile overriding the system useflags? As in
Compile foobar --with gtk --without qt
where --with and --without are lists of useflags.
> 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
The set of used flags at the time of compilation could be stored in a
Resources/ file.
But what do you mean by both directions?
> 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.
A number of proposed implementations floated around in the list over
the years (IIRC, one from Carlo, one from Andreas Koehler, and even
one mine if I'm not mistaken) and they were all variations on this
basic theme. Right now I think for Compile the cleanest would be to
have "sections" (actually shell functions) like this:
using_gtk() {
add_flag configure_options "--with-gtk"
something_else="foo"
}
not_using_ssl() {
add_flag configure_options "--without-ssl"
}
We could have smart functions to cover common cases such as "when
using gtk, add --with-gtk, but remove it otherwise":
when_using_gtk configure_options "--with-gtk"
> I also don't know how this would interplay with binary packages. So
I think we should go the simple route there: for binary packages,
define a fixed set of use flags, and use them consistently in all
packages from the repository. If people want to tweak their system at
use flag level, then they should follow the ways of the source.
> 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.
Yeah, let's keep the brainstorm going.
-- Hisham
_______________________________________________
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
