[SM-Discuss] Being about choice is knowing where to stop
Sergey A. Lipnevich
sergey at optimaltec.com
Thu May 12 14:21:24 EDT 2005
Regardless even of what we vote, people are interested in certain areas
continue to work on them, with dual 32 and 64-bit platform being a good
However, just note that in your particular example of bug 8869, the
we had was useless for the user because it essentially didn't work (I
feature itself is not to blame, it's the spell's problem, but the whole thing
didn't work in the end). Moreover, I had never used this --cflags feature, or
even the "customize configuration" feature of sorcery, I always disable it
because that's one less question in the long string of cast questions. On the
other hand, I was on a number of occasions interested in what exactly are
CFLAGS and configure options fed into the build, but alas, there's no way to
know this in general, especially for non-configure spells; we don't retain or
manage this information. Meaning, there's no easy user-accessible
answer to the
question "what options was this spell built with," as well as backup and
restoration of these options for troubleshooting. Or for example, we have many
spells that have BUILD file just for the purpose of adjusting OPTS variable,
instead of having a simple declarative way of doing that and reducing
complexity and number of files.
I think it's time to be smarter about choices we provide, that's all.
Quoting Seth Alan Woolley <seth at positivism.org>:
> Sergey, I sympathize with your comments, but see:
> Users are filing bugs on the most _obscure_ of customized hacks.
> I think we should leave the decision of what to support in the hands of
> the developers. Yes, it's a whole hell of a lot to support odd CFLAGS
> like that, but we have the WONTFIX variable. As QA Team Leader, I've
> set a few WONTFIXes or LATERs myself.
> The last thing we want is to become the patch-hell that is gentoo
> portage, and Andrew's put us on the correct track (like grimoire
> FUNCTIONS allowing the spell writer to extend sorcery themselves without
> having to patch sorcery and get a new release) in this regard.
> I think though that md5unpack (which was something I think I helped
> introduce) isn't as important as, say, full-tree-aware dependency
> resolution and cast ordering on partial rebuilds and updates.
> So I say, let the developer decide, and if there are conflicts, let's
> vote up or down on it, all together, as developers.
More information about the SM-Discuss