[F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl)

[David Woodhouse]

On Sat, 2007-04-28 at 15:15 +0200, Axel Thimm wrote:
> And as the contents of your mail that quote both Jesse's and mine
> numbers that we "seventy-odd" apart show you had read that mail. So
> the above is more than not reading, it shows that you are lying
> now. If you resort to lies then please try to pass them in a less
> obvious way.

Axel, you're really making yourself look silly here. You'd already used
the number 3074, but without explanation. Your _original_ use of that
was even still present in the quotations where I said 'seventy-odd'. I
didn't need to read your later mail to come up with that.

Anyway, I think your mirror seems to be corrupted. Even today, there are
only 1974 packages matching *.ppc.rpm at
ftp://download.fedora.redhat.com/pub/fedora/linux/core/development/ppc/os/Fedora/

Perhaps you've been rsyncing without the '--delete' option? Or had you
copied the Extras packages in to make it look bigger?

It's amusing to observe that the only figure for which you've actually
provided your calculations doesn't seem to be genuine. You're doing a
remarkably good job of applying the classic Ad Hominem to yourself here.
I've certainly stopped taking you seriously.

> > You said, in <20070427074939.GB31607 at neu.nirvana>:
> > 
> > -> o Rewrite almost all specfiles to sub-subpackage *-bin and manage the
> > ->   conflicting bin suppackages
> 
> Where does this reference "packages that contain bin and libs"? Why do
> you continue to do apples vs oranges? Why don't you *read* before
> replying?

I compared your estimate of the number of specfiles we'd need to modify
("almost all"), with mine ("10-20%"). Why do you find that so confusing?

> > Christian said he was 'hardly convinced that represents "almost all
> > specfiles"', and I did a very quick estimation of some numbers,
> > coming up with a figure of about 10% or suggesting that we could
> > push it up to 20% if we calculate differently. Then I accepted your
> > 'correction' of 14%, and you still seem to want to go on about it.
> 
> The 14% was a correction of your "we only need to split bins of libs"
> revised model, not the real fact that you need to keep bins everywhere
> in their own sub-subpackage. That's why it's a sub-subpackage. Please
> try reading before replying.
> 
> So let's really count the packages that are affected. This involves
> all package that have bins bundled together with something else, not
> only libs, but config files, %lang and %docs. Out of 4468 specfiles
> this affects 2616 which amounts to 59%.

No, now you've started making stuff up again. The proposal is only that
binary files should conflict. There's no need to make config files,
translations and docs conflict too.

You are, again, making stuff up to inflate the numbers -- which is
weird, because the numbers really don't matter anyway. Even if we did
have to touch every specfile in the distro -- like we did to change from
'Copyright' to 'License' -- if it's the right thing to do then it's the
right thing to do. As I said, we've spent too long taking the easiest
short-term 'solution' for multilib instead of really planning for the
future.

Being anal about the numbers just makes you look disturbed, especially
when you go to such lengths to make them up.

> I'll admit I would expect more ("almost all"), but whatever quanity
> anyone associates with "almost all", 59% is nearer to that, than to
> "10%". FWIW, even if I had said 100%, I would be a factor of 1.7 off,
> while you are a factor of 5.9 off.
> 
> > I probably should have listened to those who told me to ignore you as a
> > kook,
> 
> Thanks for continuing to teach me adolescent behaviour. I was warned
> that you are easy on offending other people, but I wasn't aware that
> you resolt to vulgarism.
> 
> > and not bothered to work out the numbers.
> 
> You didn't, you provided sloppy to bogus numbers all along with a hit
> bogosity of a factor of 15! And when presented with the real numbers
> you tell people that they masturbated. A very adolescent and
> professional behaviour.

Axel, I really can't be bothered to argue with your hyperbole. My
original figures were close enough to your earlier estimate of 14%;
you're having to make stuff up to vary them -- and it doesn't matter
_anyway_.

> > As I already said, it doesn't actually matter anyway. But I was
> > willing to give you a chance to prove them wrong and listen to what
> > you had to say.
> 
> I did prove you wrong. Does that account to an apology for telling me
> that I masturbate?

The phrase 'masturbating over the precise numbers' or whatever it was
that I said is a _metaphor_. Not a literal accusation of self-abuse.
Seriously, grow up. I don't know why it touched a nerve -- and I don't
_want_ to know. Just get over it.

> > I think I've probably heard enough now.
> > 
> > > Let me summarize:
> > > 
> > > o sloppy to bogus stats and metric
> > 
> > The stats were very rough, yes -- I was only trying to back up
> > Christian's assertion that it wasn't "almost all specfiles". But since
> > they were so rough, I provided the working to go with them, so that they
> > could be improved if anyone cared. You did seem to care, and you
> > 'corrected' me. My original estimate was the lower end of the 10%-20%
> > range. You corrected it to 14%, which I accepted readily. It really
> > doesn't matter.
> 
> Don't twist the numbers. I corrected some numbers that you produced,
> but the set of specfiles to fix (59%) are still closer to "almost
> all", than to "10% with and overestimated 20% upper bound".
> 
> > > o misquoting
> > 
> > No, I think you're getting confused again. Every misquote I've seen has
> > been from your side. I really have no need to resort to such tactics --
> 
> But you did, in this very last mail again. I never refered with almost
> all to bins-with-libs packages as you like to present it, and even
> after correcting you as many times, you still present it that way.

I presented precisely what you said -- your claim that we would need to
"rewrite almost almost all specfiles". In fact, we'd only need a
relatively minor modification to maybe 14% of them.

That figure only becomes 59% if we take your radical new suggestion of
banning conflicts even in text files, which I suggest we should not do.
I assume you weren't seriously proposing that, and it was just a way to
inflate the numbers some more?

> > especially when you harp on about the numbers I've already agreed with,
> > and send mail like the one I'm replying to.
> 
> Which you reply to w/o reading or understanding.
> 
> > > o vulgar talking
> > 
> > Yep, because that's really relevant to a technical conversation.
> 
> Well, I'm glad that you informed us about your style of technical
> conversation, but I'm surely not allone if I ask to to refrain from
> this immediately.
>
> And please add
> 
> o lying
> 
> to the list of your contribution in this thread.

Heh. I really don't know who you're trying to fool any more. You seem
like an intelligent person -- you can't possibly have genuinely thought
I was lying. Do you really think anyone's reading this thread and taking
you seriously when you come out with stuff like that? The Ad Hominem
doesn't work when you make yourself look more foolish than the person
you're slandering.

Concentrate on the technical discussion, please. We'll let those reading
the archives judge whether they think I'm a liar or not.

> > > are Mr. Right's contribution for a long-term, not short-sighted
> > > solution for the multilib problem.
> > 
> > I do appreciate the accolade, but there is no need for you to call me
> > 'Mr. Right'.
> 
> Do you prefer Mr. Vulgar?

If you like. It doesn't detract from the technical conversation; it only
makes you look foolish. Call me what you like, by all means.

If it's all the same with you, I'll continue calling you 'Axel'.
At least in public fora.

> > The technical side of the conversation stands up on its own.
> 
> Indeed. Not only are the amount of packages to adjust to your proposed
> model the majority indeed (59% specfile wise), but your model implies
> file-level conflicts on all these 59% of packages that
> rpm/yum/anaconda/smart/apt will choke on, does not allow coinstalls
> and requires a switch from one arch to another to redownload the
> packages.

Your 59% is misleading; you changed the rules to get to there from the
14% you earlier came up with. Not that it matters.

I cannot speak for smart and apt, but rpm/yum/anaconda certainly don't
have an issue with the existence of multiple packages which provide the
same file -- we have that already, anyway. It all works fine, as long as
yum and anaconda only try to install one at a time by default (which is
already the right thing to do anyway; bug #235756). You've been told
this before, and yet you still keep repeating the same nonsense.

And yes, just as now: if you want to switch the binary from one arch to
another, you need the original package of your desired arch available.
Although it becomes a lot easier to switch than it is now, because when
we get rid of the dirty hack in RPM to allow conflicts, bugs like
#235524 go away.

> > Thank you, and goodbye.
> 
> I'm still seeing you on these lists. I guess if you stop using
> vulgar talk you could stay.

Thanks. That's very kind of you.

-- 
dwmw2