On Apr 28, 2012, at 10:31 AM, Per Øyvind Karlsen wrote:
> 2012/4/28 Jeffrey Johnson <n3...@me.com>:
>>
>> Well your overlapping dependencies removal checked in upstream is about
>> to get ripped out for lack of generality and bugginess.
>>
>>
Confirmed not upstream (whatever that means: increasingly I cannot build
or run @rpm5.org from CVS anywhere, not even on Mandriva/ROSA, outside
of the build tree.
> Perfectly understood, I didn't even think that I had commited it upstream?
> If so, it must've been done under a #ifdef or something?
>
And the days where
#ifdef RPM_VENDOR_FOO
are numbered.
An #ifdef was fine for small/simple changes, or for non-production
code paths like Mandriva file triggers (its a pure side-effect that
doesn't affect what RPM is intended to do).
But a #ifdef isn't working when there are entire behavior changes
and 124 unreviewed "wild hacks" floating about that make it
increasingly impossible to tell what behavior rpm SHOULD have.
I have zero tolerance for
Have it your own way!
development these days. Merge or reject as soon as popsicle
is the path I'm on instead of this feeping creaturism random walk
that tends to revisit "legacy compatibility" as an attractor on
a chaotic trajectory.
> As I don't consider any of it ready for upstream or general enough, it's no
> problem, I'll be continuing my work on and improving these things gradually
> outside of upstream, then I'll start address these issues you bring up as well
> when I get to your latest code. :)
>
If it not read for "upstream", then why inflict buggy "dog food" on users?
There's a serious "rpm therapy" cost discussing at the bikeshed ad nauseam.
And there are no "the dog ate my homework" excuses readily at hand.
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
