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

Tue May 1 09:32:19 UTC 2007

I'm removing all your references on masturbations and characterizing
me as a kook and the like. Please don't readd them or any other new
non-adolescent vocabulary.

On Sat, Apr 28, 2007 at 04:31:22PM +0100, David Woodhouse wrote:
> > > -> 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?

No, you wrongly quoted my 14% as confirming the validity of your
estimation, which I now repeadetly explained that this is not the
case. All it was was an exact number of the set of specfiles *you*
specified as relevant which is not the set of specfiles that would
need modification.

So if you say everything here is fruits and there are 10% apples, and
I tell you, that we need to count oranges, which is a much higher
number, but anyway there are 14% of apples around here, you conclude
that I verified that we only need to count apples, and that 14% is the
correct number. Don't compare apples and oranges.

Hope this analogy makes it clear.

> > > 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.

Really think this through to the end including your suggested user use
cases. Do so, and then check what the bin swapping will cause. Or just
read the example below if it doesn't strike you.

> 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.

And the suggestion to split all bins into sub-sub-packages is just
such a easy short-term solution. Even if we magically get the split
done or ignore the required man time it

o creates file conflicts in the repo by design
o thus borks yum, anaconda, smart and apt
o Requires users to redownload packages each time they wish to simply
  switch from foo-32 to foo-64
o Breaks the majority of config files (that's where the 59% come from)

> Axel, I really can't be bothered to argue with your hyperbole. My
> original figures were close enough to your earlier estimate of 14%;

Remember, you apples, me oranges.

> > > > 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.

If you allow for your scheme to nuke config files, sure. But that's
not what we'd like to have.

> 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.

Then watch how switching from foo-32 to foo-64 undoes the users' config.

> I assume you weren't seriously proposing that, and it was just a way to
> inflate the numbers some more?

I _never_ _ever_ did say that the only thing we would have to do is
seperate bins from libs. So this is not something new, for me it was
clear from the beginning that your model will have to evolve to
sub-sub-packages containing only bins, and I wrote that a miriad
times, but you were reading over it.

Examples do seem to work better, so let's try once again.

# foo
<the 64 bit version doe not work as expected, let's try the 32 bit version>
# yum remove foo
foo is required by bar, baz, barbaz, bazbar, ...
[Y,n]: n
<rant, rant, rant>
# rpm -e --nodeps foo
/etc/foo.conf is saved as /etc/foo.conf.rpmsave
# yum install foo.i386
<wait, wait, wait>
# foo
foo has not been configured
<huh? rant, rant, rant>
# mv /etc/foo.conf.rpmsave 
# foo
<ok, doesn't work in 32 bits either, let's switch back, argh ...>

So a short-sighted, short term solution once again. you want to do it
"right"? You need to make sure the bins don't get packaged together
with config files. So that does explode the 14% of just-need-to-split-
bins-and-libs to a higher number, right?

Not making up anything, just pointing to the flaws of your proposal.

> > > 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.

Apples and oranges once again. No change of rules, you always read
over my posts, why did I say that every subpackage needs to split out
the bins into sub-sub-packages from the very beginning?

> 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.

The above example and all others used yum. And yum does get very angry
if there are packages in it's repo-world that conflict on file level.

Heck, we even had a guideline rule created exactly for that: Every
file conflict needs to be made a package conflict, because yum
(rightfully) doesn't like that. And that would not be even possible
with your scheme because Conflicts: does not take an arch.

So, the proposed sub-subpackaging of bins is flawed from all
corners. And the resitance you're feeling from me and seems to make
you angry and offensive is just the preview of what rpm and yum
maintainers will greet you with once they realize that your scheme
needs them to rewrite their tools.

No easy short-sighted and short-term solutions was your slogan, stick
to it.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20070501/20291df4/attachment.sig>