On Apr 22, 2012, at 1:07 PM, Matthew Dawkins <mdawk...@rpm5.org> wrote:
>
> @@ -1128,6 +1132,12 @@
> }
> }
>
> + /* XXX ugly quick & dirty integration of haskell() dependencies */
> + { fn = strstr(fc->fn[fc->ix], "/usr/share/haskell-deps");
> + if (fn)
> + fc->fcolor->vals[fc->ix] |= RPMFC_HASKELL;
> + }
> +
> if (fc->fcolor->vals[fc->ix])
> for (fcat = rpmfcApplyTable; fcat->func != NULL; fcat++) {
> if (!(fc->fcolor->vals[fc->ix] & fcat->colormask))
> @@ .
As discussed on IRC privately, patches like this
are increasingly unacceptable for several reasons:
1) strstr(3) has hidden state that WILL break
with multithreading. And the proper fix isn't
to just use strstr_r(3).
2) RPM runs on non-linux with software hierarchies
that aren't just --prefix=/usr as Linux bigots are
used to. I will start rejecting patches that aren't
general in the ${prefix} sense rather than retrofitting repairs.
3) atm RPM+HASKELL are casual acquaintances with no
well understood usage case or need. I.e. none understands
what is needed, and so hacking in _SOMETHING_ is likely a
waste of time. It does take *years* to get rid of naive hacks
patches in RPM (and there are zillions of examples of
creepy hacks that are likely useless (but its impossible
to tell and the risk factor as always is de facto
This used to work!
You've been warned … (and nothing at all wrong with the check-ins:
what is really needed here is swiping @rpm.org's framework for
handling patterns through macros, not integrating all these
automagic dependency extractors item by item and listening to
me point out all the flaws. But that is a design/architectural issue ...).
hth
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
