On Tue, Oct 22, 2002 at 01:57:07AM +0200, Santiago Vila wrote: > On Mon, 21 Oct 2002, Ben Collins wrote: > > > > It's not just that things are not in sync, it's that you are artificially > > > forcing them to be in sync without need, and every time they aren't, > > > an important package like locales becomes *completely* uninstallable. > > > > > > Do you still think "most people don't use locales", Ben? > > > > > > Oh no, I understand that most ppl use locales. The issue is not that. > > Most ppl use i386, so most of the ppl who use locales are unaffected. > > > > The point is we have a real reason that the locales dep is the way it > > is. it's not artificial. Old bug reports forced this issue. We will also > > continue to pull CVS to keep glibc in sync. Hand picking patches from > > CVS for individual problems makes upkeep that much harder, especially > > when the next stable comes out. > > Ok, I understand that you want to keep in sync with CVS, but it is > really true that the locales code still changes so often in an > incompatible way? > > The glibc-$DEBVERSION virtual package which libc6 provides seems very > similar to the shlibs info, which, if I'm not mistaken, it is updated > "when there is a need to". Is there a reason (other than "it's easier") > why the string used for this dependency could not be updated as well > "when there is a need to"?
It does change, and it changes irrelevant of the shlibs. The data is subject to arbitrary change because the only thing that should touch it is glibc itself. Because of that, tiny changes in the internal data structures can render it useless on other machines. > > The fact is, you are also quite incorrect in your assesment. The problem > > only affects two instances: > > > > 1) New installs from sid (rare seeing as we don't have a sid installer) > > You are speaking as a i386 user. ROFL. I do not even have an i386 machine here. > This is not so rare for unreleased architectures, since sid is the > *only* existing distribution. In fact, "I'm using sid" is a meaningful > sentence for a i386 user, since he/she could be using woody or sarge > instead. For unreleased architectures it's somewhat meaningless, > since there is no other distribution to choose from. I can't do anything to make sure an unreleased architecture is in any sort of installable state. That being said, I am quite sure this problem affects more than libc6. I have experienced it in other packages on _released_ architectures. > Currently it's a real pain in the ass to try to install the Hurd from > scratch, or upgrade it, when the locales and libc packages are not in > sync. You have to edit /var/lib/dpkg/status by hand and edit some of > the Provides field. > > I guess that the same is true for all other unreleased architectures. > > If we do not make unreleased architectures usable enough, they will > never become stable enough to be released. My point is that > unreleased architectures should not be second-class citizens, > as far as useability is concerned. I don't buy this. The fact that the architecture cannot stay in sync with glibc means it is not stable enough to release. That's not directly or indirectly related to locales. I seriously doubt the RM's will ever say "Oh, locales cannot be installed from scratch on this arch, it cannot be released". More likely you would hear "Oh, latest glibc cannot be built for this arch, so it cannot be released." The fact that locales is not a base package further rejects your claim. > So, if we want unreleased architectures to be useable, we should > either eliminate "=" dependencies of very popular arch:all packages on > essential-de-facto arch:any packages, or we should create a testing > distribution for them. No, the reality is that glibc wont be upgraded that often. This one time was just a fluke because of a serious problem. Going from 2.2 to 2.3 is a serious jump and problems like this can be expected. Things will stabalize from here out. > If you are not willing to do anything about the dependencies, please > let us agree that a testing distribution is *really* needed. I wont agree. This is a passing phase, just deal with it in the meantime. The locales package is not needed for stabalizing hurd. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/
