On 7/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On 7/2/07, Michael Homer <[EMAIL PROTECTED]> wrote:
> > On 7/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > I am very wary about how this would be determined (thinking about
> > > community/social/flamewar implications, rather than technical issues).
> > > I'd rather avoid this can of worms and stick to something that can be
> > > unequivocally determined, reducing the spectrum to "required",
> > > "optional" and (the eventually phased-out) "unlabeled". Even then,
> > > there is always the issue of app-specific flags and whether they will
> > > be enabled or disabled by default (where being enabled by default
> > > amounts to being "recommended" and disabled by default to being
> > > "discouraged", I understand.) So, yes, to some degree it is an
> > > unavoidable problem (unless you want to shy away and ask the user
> > > everything). But its an unsolvable problem in the global sense, as
> > > it's impossible to make _everyone_ happy with the chosen defaults, but
> > > then that's why they're just "defaults" and not hardcoded behavior.
> > > (All right, I'm just rambling, throwing ideas to the table. I haven't
> > > made up my mind on this issue.)
> > That's the same wariness I have. But there are going to be things that
> > default to on without being mandatory, so it's going to come up no
> > matter what. What goes into the binary packages has much the same
> > issue, and it hasn't been a problem, so it would probably be ok.
> >
> > However, after some thought I'm not sure how much "recommended" would
> > be used, at least as I saw it. I was thinking of "it is recommended
> > that you enable SSL support for security reasons" as an example. I'm
> > less keen on "it is recommended that you enable GTK+".
> >
> > So it might be an area best avoided. The profiles idea Isaac suggested
> > could help. I think that has many of the same problems, though, and
> > the combining part looks a little confusing. If there are going to be
> > different profiles anyway, as has come up from time to time, I think
> > it'd be a good way to do them.
>
> Agreed. It's an unavoidable problem (as choices have to be made at the
> very least for binary packages) and I agree that Isaac's idea of
> taking the decisions of what's recommended and what's not out of the
> recipes and into profiles is a good one. (And I also found the
> profiles part confusing :) )
So do I (or I think the complexity might be in the wrong place,
really), but the general thrust of it is good if we're going to go
that way. And it would make a lot of things easier, especially if they
can be layered. We have to give some thought to what would be the best
way of doing it is all.
> > Wearing my Freshen hat for a moment, I'm actually not that fond of
> > anything that requires prompting the user and isn't avoidable. So I
> > would prefer that asking never happen, and that there be some way to
> > determine if there's a conflict and just die right at the beginning.
>
> What I'd love to have is a list of "stable versions" that Freshen
> could download and use, listing versions for all recipes so that "for
> the programs you have, if you have _these_ versions-revisions
> installed, they'll all work". Maintaining that list, though, is the
> trick for having a stable distro.
That would be nice too. The same thing could be achieved with recipe
repository branches right now (like how Debian stable/testing works).
A list might be nicer in case of downgrades, to order things in a
particular way. Whether this would all be genuinely useful I don't
know, but it could be made part of the release system: just change
your profile to 014 and update to get a stock system instantly.
That doesn't much help in the asking case, though. I don't like the
idea of asking questions during the flow, and I very definitely want
to know all the dependencies in advance of starting the compile.
Asking means the results from Freshen and Freshen -U might not be the
same, and requires repeating all the answers. But I'm not sure how
else to resolve conflicts, other than flat-out prioritising. Which
might not be so bad, come to think of it, so long as the profiles were
specific enough.
>
> > > > > 2) Dependency Flavors would not handle the case of Compiling only a
> > > > > specific Xorg video driver. I believe "USE-flags"/Flavors should be
> > > > > used for cross-recipe configuration, not intra-recipe configuration.
> > > > > I'm not opposed to intra-recipe configuration mechanisms, but I think
> > > > > intra-recipe configuration is a separate (and much simpler) problem,
> > > > > and should be solved separately and without cluttering up the global
> > > > > "USE-flag" namespace.
> > > > It is cross-recipe. The recipe "Xorg" depends on the recipe
> > > > "XF86-Video-I810".
> > >
> > > I think solving intra-recipe and cross-recipe issues with the same
> > > mechanism would be better. Being pragmatic, I don't think cluttering
> > > up the "USE-flag" namespace is that big of a deal. Two things should
> > > help: one is avoiding to fall into the trap of trying to map every
> > > available configure flag; another is to define some namespace rules
> > > such as "if a flag is used in only one program, it must be prefixed by
> > > the program name".
> > I'd like to be careful about doing that, since it ties us down in case
> > something new comes along later. We don't want our flag called
> > "xorg-video-i810" only to find out later that Xine has direct support
> > for the card too (not an artificial example, it really does). So
> > prefixing should only be in the cases that are genuinely specific to
> > one program, semantically.
>
> I was thinking along the lines of expanding the namespace in an
> as-needed basis. A flag could start as "xorg-video-i810" and then when
> we realize we can use it on other package we'd add a "video-i810" flag
> and make the old flag an alias to the new one.
That would work. It sounds pretty much perfect, in fact, although it
would be nice to have the aliases get cleaned out every so often to
avoid confusion ("Do I need to enable video-i810 AND
xorg-video-i810?"). That's minor though.
-Michael
_______________________________________________
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
