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"? > 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. 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. 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. > 2) Ppl who did not originally have locales installed, but upgraded to > sid, and later decided to install locales. Since this only affects the > random non-serious user of locales, I don't think it affects you or the > "hardcore locales users" you seem to be defending. It's more "users of unreleased architectures", really. > If you are following sid with locales installed, apt will not allow you > to upgrade locales. Of course your currently installed version will > remain working. What's broken about that? Nothing at all that I can see. Again, you seem to speak as a i386 user. There is no such concept of "upgrading to sid" for a hurd-i386 user. They are always running sid, because there is no other distribution to choose from. If they are not even able to install sid from scratch, they hardly will be able to upgrade from the sid-of-yesterday to the sid-of-today. There is a breakage that you don't see: Say that a hurd-i386 user has glibc-2.2 and locales-2.2 installed (I'm dropping debversion numbers for clarity). Say that you upload glibc-2.3 and locales-2.3 for i386, which are recompiled for hurd-i386, and the day after, you upload glibc-2.3.1 and locales-2.3.1, which are not recompiled for hurd-i386 yet. Well, if the hurd-i386 user didn't upgrade to glibc-2.3 and locales-2.3 the day they were both available, he/she will not even be able to upgrade from glibc-2.2 to glibc-2.3 the day after, because that would break locales dependency and apt will not let you to do that. 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. If you are not willing to do anything about the dependencies, please let us agree that a testing distribution is *really* needed. Thanks.
