-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[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.)
Maybe there are different typical usage profiles with different normal
choices. For example, "Server" versus "Desktop", perhaps "KDE-Desktop"
or "Lightweight-desktop". This is obviously a quite horrible idea. So
let's try to fix it. Maybe they are just listings of mpb's "Policies"
idea. To separate "required" and "optional" dependencies makes sense in
the recipe; we may want to keep any recommendations, which are
"political", out of recipes and entirely in Policies files, which can be
distributed. Now to fix them: WE WANT TO COMBINE THEM! What if I want
to run a machine as both a desktop and a server? What if I want to make
a few customizations to the default Desktop profile (these profiles are
in some sense strictly third-party, but we obviously have to make some
choices for official LiveCD's at least, and do something with official
binary packages) and keep my customizations with me for use in later
installations, but using a newer version of the Desktop set of Policies.
Let's invent some hypothetical policy-set-combinators:
Combine_Ask Desktop Server #wherever their recommendations conflict,
don't use either recommendation, ask the user.
Combine_Override Desktop Server #wherever the second one gives a
recommendation, it takes precedence over the first one
Combine_Greedy Desktop Server #enable all that either recommend. Not
sure whether this would usually work, or would tend to break things.
Now let's try something.
Combine_Override (Combine_Ask Desktop Server) MyChoices
wouldn't ask you much, if you resolved the issues in MyChoices policy
set. Maybe you could set it up so that choices you make are
automatically put into MyChoices or something. Maybe if this combined
profile was common and the extra choices were almost always the same,
someone would make a DesktopServerConflictResolutions and
DesktopServer = Combine_Override (Combine_Ask Desktop Server)
DesktopServerConflictResolutions
Maybe every user (every goboPrefix, rather) would have a custom editable
local-policies file somewhere. If not found, it would just have to ask
you about every dependency (unless there was an implicit
Combine_Override Something LocalPolicies... maybe Something pickable at
install time).
(one possible default that could be set is always choose "yes" for
anything already currently installed if not specified otherwise - I
would not choose such a default)
Some false Optional dependencies can be automatically caught by
compiling with and without the dependency: if the
ChrootCompile-generated package is exactly the same both ways, it's
clearly not that kind of dependency. (Unfortunately this is broken
relative to time of compile / system clock, as well as the possibility
that presence/absence of other optional dependencies affects it.)
Is it common that it would be necessary to add a configure option or
equivalent in order to enable the use of an optional dependency?
Hopefully any of those ideas can be used non-horribly; I'm not sure =)
Isaac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGiRefHgcxvIWYTTURAvpUAKCXnQqxFdi43VHf+vewt4tuLrW63QCfRYmj
ZMAHAayIHMSIDjgoSeSRaR8=
=qEit
-----END PGP SIGNATURE-----
_______________________________________________
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
