[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: the Great X Reorganization, package splits, and renaming



On Tue, Jan 26, 1999 at 12:42:18PM +0100, Santiago Vila wrote:
> Can you *guarantee* that the package now called xfonts-base will *always*
> have the same functionality and will always be *identical* to the one
> called xfntbase in hamm?
> 
> Can you *guarantee* that the package now called xlib6g-static will
> *always* have the same functionality and will always be *identical* to the
> one called xslibg in hamm?
> 
> I don't think you can, unless you have a crystal ball.

I don't have to.  If and when a package has non-practically-identical
contents (I fear not qualifying it, for I'm sure you'd file a critical
bug against xfntbase for not having the same changelog.Debian as
xfonts-base) from its predecessor, if dpkg/apt have not implemented
brains sufficient to account for package renaming, I will implement your
ham-fisted solution, *for the affected package(s) only*.  I did this very
thing for xbase.

> But then it could be too late. Sorry but this is vaporware.

If changes in the font and static library packages haven't happened by the
time potato is released, it still doesn't matter, for the same reasons it
doesn't matter now.

> It is not wise at all to rely on features that have not been implemented
> yet. As Joseph Carter says: "Show me the code or get out of my way".

I'm not relying upon them.  Hamm and older systems upgrading to slink break
in no particular fashion because of the existence of the new packages.

> BTW: I see a contradiction here... If you and Branden are so sure that
> package ranaming will be implemented in dpkg for potato, why does not
> Branden just postpone all the package renamings to potato to do it the
> right way?

Because it's too late.  They've already been renamed.  If I had
appreciated the difficulties this would have caused me four months
ago when I first drafted my proposal, I would have renamed only two
packages -- xbase and xfntbig.  I would have let the rest wait for more
support infrastructure from our packaging system.  I was much less
aware of dpkg's limitations at the time.  The X Strike Force webpage
has been up for almost a year, and has contained detailed plans of the
X reorganization as long as I've had them.  Only now do you seem to be
concerned.

> Frankly, I'm very suprised how low do you value the userfriendliness of
> the system, the smoothness of the upgrades and the overall quality of
> Debian. I can't accept "I create a problem today and will fix it
> tomorrow" or worse "problem? what's the problem?".

Yes, I'm certain if one tallies up all the outstanding bug reports I've
managed to fix in X, some of the new functionality I've managed to develop,
and Marcus Brinkmann's XF86Config diagnostic tool, one could easily reach
the conclusion that I don't give a damn about the user friendliness, smooth
upgrades, or overall quality of Debian.

> Upgrading a system from hamm to slink should make the system to be in the
> same state as if slink had been installed from scratch.
> 
> Otherwise, Debian will become just a W95 clone very soon (have you ever
> asked yourself why people reinstall W95 so often?).

This is a straw-man argument.  Isolate one criterion -- if we don't meet
that by YOUR standard, we're no better than Windows 95.

Are you a university student?  I suggest a course in critical thinking.

I reiterate my challenge.  Demonstrate to me a manner in which a
hamm system upgraded to slink, which keeps the old X font and static
library packages, will be broken.  What programs will break?  What
statically-linked X clients will they be unable to build, or in what
manner will these clients differ from their counterparts build with
xlib6(g)-static?  What fonts from the xfnt* packages will they be
missing out on if they don't install the corresponding xfonts*- package?

I've levelled this challenge before, and you've only been able to reply
with more flamage and illogic.  I told you, demonstrate a significant practical,
functional drawback to leaving the old packages in place and I will
implement the bizarre pseudo-packages.

These are the practical, important considerations.  I, too, would like
people's systems to be rid of the old packages.  But I'm not going to
pervert the packaging system to do it without some more cause to do so.

-- 
G. Branden Robinson              |    Convictions are more dangerous enemies
Debian GNU/Linux                 |    of truth than lies.
branden@ecn.purdue.edu           |    -- Friedrich Nietzsche
cartoon.ecn.purdue.edu/~branden/ |

Attachment: pgpaUkgrLYgqR.pgp
Description: PGP signature


Reply to: