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:
pgpsBgqXiXIO4.pgp
Description: PGP signature