Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
GOTO Masanori wrote: Santiago Vila wrote: GOTO Masanori wrote: How many uninstallable period do you have? Undefined. May be a short time, but it may be a lot of time as well. I wonder why such delay was occured. locales package is built with libc6. I'm surprised that you ask this. libc is Architecture: any. locales is Architecture: all. When you upload a new libc+locales for i386, libc and locales stop being in sync for unreleased architectures like hurd-i386, because the locales available is the new one uploaded by you, while the libc is the last compiled version. I think you can make '='-type dependency in locales to be something slightly different which achieves the same desired result without harming unreleased architectures so much. The DEBVERSION thing is arbitrary, in some sense. You just need a character string which has the property that it changes every time there is an incompatible change in the locales code. Certainly, DEBVERSION has such property, since it *always* changes. The problem is that most of the time it changes without real need. You could also use a character string of the form locales-DATE, and update DATE when (and only when) an incompatibility in the locale code is detected. Hmm, it increases our maintenance cost. I don't want to make us be such difficult rule. It's a quite simple rule, not a difficult one. In fact, I think it should be *much* less work for you than the work it imposes on hundreds of people who have to workaround the too-much-harcoded dependency by editing /var/lib/dpkg/status manually just to be able to cheat dpkg into thinking that the available packages are ok to be installed simultaneously, which is what actually happens most of the time. Moreover, it loses libc6-locales package version consistency. I dislike such locales-DATE name. This is merely an aesthetically issue that should not be taken in account. A name is just a name (remember what Shakespeare said about the rose?). You could use glibc-2.2.5-last-one-that-had-to-be-changed and update it to the current version when there is a need. Or you could just drop the name entirely and reintroduce it if the problem reappears. You can use whatever name it looks nicer for you, as far as it changes whenever the interface changes, but changing the name at every release without a *real* need is gratuitous and wrong, IMHO. As a matter of principle, a package should depend on what it *really* needs. In addition, from my point of view, your idea stands only 'delaying locales package inconvenient for me, it's suck, the version difference mitigation is the best way for my architecture, and I have no relation to such maintenance cost or technically point/right, or package version consistency'. Your idea only focuses glibc, not general. Is it only glibc related issue? All debian users get nicely with your idea? If other package hits this problem, then you also do BTS? Consider what is the problem, please. [...] I think it's not only glibc but also more generic (other package related) issue. IMHO, it's more appropriate that we discuss at debian-devel, or modify the management of packaging system. Why do you want to fix only glibc locales package? I reported this against glibc because I think it is a bug in glibc. A testing distribution for unreleased architectures would make this problem invisible. Nobody would notice that glibc packages have a hardcoded = dependency, but that would not mean = dependencies are a good thing in general. Most of the time, = dependencies are wrong in the sense that they ask the user more than it is really needed. (Consider the case of a person who wants to upgrade to testing while minimizing the telephone bill at the same time, we could be forcing this user to upload more MB of data than it is really required). If you can use a string like glibc-2.2.5-last-one-that-had-to-be-changed, that would be a *huge* improvement over the current status, and I don't think it would be so much work for you (feel free to disagree, since you are the maintainer). On the other side, if you think (gratuitous, IMHO) = dependencies are ok and the only way to fix this problem is by having a testing distribution for unreleased architectures, then please reassign this bug to the ftp.debian.org virtual package. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
On Mon, Oct 21, 2002 at 11:15:37PM +0200, Santiago Vila wrote: On Mon, 21 Oct 2002, Ben Collins wrote: If you do not consider this a problem in libc, please reassign this to the ftp.debian.org package so that they create a testing distribution for all unreleased architectures, one that does not remove old packages until the new ones become installable. Unstable is a freaking moving target. Don't file bugs just because things don't stay in sync. That's ignorant. Exactly what part of please reassign to ftp.debian.org didn't you understand? 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. So reduce your FUD. I am not against locales, or the users of it. Quite the contrary. The mechanism exists so that locales remains in a working state. 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) 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. 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. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
Processing commands for [EMAIL PROTECTED]: reopen 164868 Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures Bug reopened, originator not changed. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
reopen 164868 thanks On Mon, 21 Oct 2002, GOTO Masanori wrote: At Tue, 15 Oct 2002 19:00:24 +0200 (CEST), Santiago Vila wrote: The dependency of locales on glibc-$DEBVERSION is harmful for non-released architectures like the Hurd, since the only locales package which exists (since there is not a testing disrtibution) becomes uninstallable until the glibc package is recompiled. I don't know why hurd is the special case. Why do you just recompile them? That's not the problem, the problem is that *while* it's not recompiled yet, the locales package becomes *completely* uninstallable, because the old version is not available anymore. If you do not consider this a problem in libc, please reassign this to the ftp.debian.org package so that they create a testing distribution for all unreleased architectures, one that does not remove old packages until the new ones become installable. Such dependency should be on glibc-$VERSION at most. The reason glibc-$DEBVERSION was required in the past was that, at some point, there were incompatible locales and libc packages having the same VERSION but different DEBVERSION numbers. This was because the maintainer was introducing new code from CVS without changing the VERSION, which may be considered as a bad practice. So, I request that the dependency is changed again to a non-debversioned one (like glibc-$VERSION) and the maintainer refrains from making incompatible changes without changing $VERSION as well. Locales should depends on glibc-$DEBVERSION, because somethimes we apply the latest glibc cvs code in the same glibc-$VERSION (and count up glibc-$DEBVERSION) as you said. Locale handling is still active development area, so we can't ignore the difference of both localedata and locale handling code. Thus, I can't accept your request. If you are going to keep a =-type dependency, you should perhaps merge both packages into a single one.
Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
GOTO Masanori wrote: Santiago Vila wrote: That's not the problem, the problem is that *while* it's not recompiled yet, the locales package becomes *completely* uninstallable, because the old version is not available anymore. How many uninstallable period do you have? Undefined. May be a short time, but it may be a lot of time as well. If you do not consider this a problem in libc, please reassign this to the ftp.debian.org package so that they create a testing distribution for all unreleased architectures, one that does not remove old packages until the new ones become installable. (1) At least we use pool system for released architecture, and some versions stay for a while. (2) Unreleased architecture does not stay and only single version is placed. You hit this case. (3) However, we can't remove '='-type dependency for locales. Thus, our discussion goes side by side. We can't agree. I think you can make '='-type dependency in locales to be something slightly different which achieves the same desired result without harming unreleased architectures so much. The DEBVERSION thing is arbitrary, in some sense. You just need a character string which has the property that it changes every time there is an incompatible change in the locales code. Certainly, DEBVERSION has such property, since it *always* changes. The problem is that most of the time it changes without real need. You could also use a character string of the form locales-DATE, and update DATE when (and only when) an incompatibility in the locale code is detected.
Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
At Mon, 21 Oct 2002 15:39:04 +0200 (CEST), Santiago Vila wrote: GOTO Masanori wrote: Santiago Vila wrote: That's not the problem, the problem is that *while* it's not recompiled yet, the locales package becomes *completely* uninstallable, because the old version is not available anymore. How many uninstallable period do you have? Undefined. May be a short time, but it may be a lot of time as well. I wonder why such delay was occured. locales package is built with libc6. If you do not consider this a problem in libc, please reassign this to the ftp.debian.org package so that they create a testing distribution for all unreleased architectures, one that does not remove old packages until the new ones become installable. (1) At least we use pool system for released architecture, and some versions stay for a while. (2) Unreleased architecture does not stay and only single version is placed. You hit this case. (3) However, we can't remove '='-type dependency for locales. Thus, our discussion goes side by side. We can't agree. I think you can make '='-type dependency in locales to be something slightly different which achieves the same desired result without harming unreleased architectures so much. The DEBVERSION thing is arbitrary, in some sense. You just need a character string which has the property that it changes every time there is an incompatible change in the locales code. Certainly, DEBVERSION has such property, since it *always* changes. The problem is that most of the time it changes without real need. You could also use a character string of the form locales-DATE, and update DATE when (and only when) an incompatibility in the locale code is detected. Hmm, it increases our maintenance cost. I don't want to make us be such difficult rule. Moreover, it loses libc6-locales package version consistency. I dislike such locales-DATE name. In addition, from my point of view, your idea stands only 'delaying locales package inconvenient for me, it's suck, the version difference mitigation is the best way for my architecture, and I have no relation to such maintenance cost or technically point/right, or package version consistency'. Your idea only focuses glibc, not general. Is it only glibc related issue? All debian users get nicely with your idea? If other package hits this problem, then you also do BTS? Consider what is the problem, please. BTW, you don't mention about below my message. What do you think? Or just reassign to ftp.debian.org? At Mon, 21 Oct 2002 20:34:54 +0900, GOTO Masanori wrote: I think it's not only glibc but also more generic (other package related) issue. IMHO, it's more appropriate that we discuss at debian-devel, or modify the management of packaging system. Why do you want to fix only glibc locales package? -- gotom
Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
GOTO Masanori wrote: Santiago Vila wrote: GOTO Masanori wrote: How many uninstallable period do you have? Undefined. May be a short time, but it may be a lot of time as well. I wonder why such delay was occured. locales package is built with libc6. I'm surprised that you ask this. libc is Architecture: any. locales is Architecture: all. When you upload a new libc+locales for i386, libc and locales stop being in sync for unreleased architectures like hurd-i386, because the locales available is the new one uploaded by you, while the libc is the last compiled version. I think you can make '='-type dependency in locales to be something slightly different which achieves the same desired result without harming unreleased architectures so much. The DEBVERSION thing is arbitrary, in some sense. You just need a character string which has the property that it changes every time there is an incompatible change in the locales code. Certainly, DEBVERSION has such property, since it *always* changes. The problem is that most of the time it changes without real need. You could also use a character string of the form locales-DATE, and update DATE when (and only when) an incompatibility in the locale code is detected. Hmm, it increases our maintenance cost. I don't want to make us be such difficult rule. It's a quite simple rule, not a difficult one. In fact, I think it should be *much* less work for you than the work it imposes on hundreds of people who have to workaround the too-much-harcoded dependency by editing /var/lib/dpkg/status manually just to be able to cheat dpkg into thinking that the available packages are ok to be installed simultaneously, which is what actually happens most of the time. Moreover, it loses libc6-locales package version consistency. I dislike such locales-DATE name. This is merely an aesthetically issue that should not be taken in account. A name is just a name (remember what Shakespeare said about the rose?). You could use glibc-2.2.5-last-one-that-had-to-be-changed and update it to the current version when there is a need. Or you could just drop the name entirely and reintroduce it if the problem reappears. You can use whatever name it looks nicer for you, as far as it changes whenever the interface changes, but changing the name at every release without a *real* need is gratuitous and wrong, IMHO. As a matter of principle, a package should depend on what it *really* needs. In addition, from my point of view, your idea stands only 'delaying locales package inconvenient for me, it's suck, the version difference mitigation is the best way for my architecture, and I have no relation to such maintenance cost or technically point/right, or package version consistency'. Your idea only focuses glibc, not general. Is it only glibc related issue? All debian users get nicely with your idea? If other package hits this problem, then you also do BTS? Consider what is the problem, please. [...] I think it's not only glibc but also more generic (other package related) issue. IMHO, it's more appropriate that we discuss at debian-devel, or modify the management of packaging system. Why do you want to fix only glibc locales package? I reported this against glibc because I think it is a bug in glibc. A testing distribution for unreleased architectures would make this problem invisible. Nobody would notice that glibc packages have a hardcoded = dependency, but that would not mean = dependencies are a good thing in general. Most of the time, = dependencies are wrong in the sense that they ask the user more than it is really needed. (Consider the case of a person who wants to upgrade to testing while minimizing the telephone bill at the same time, we could be forcing this user to upload more MB of data than it is really required). If you can use a string like glibc-2.2.5-last-one-that-had-to-be-changed, that would be a *huge* improvement over the current status, and I don't think it would be so much work for you (feel free to disagree, since you are the maintainer). On the other side, if you think (gratuitous, IMHO) = dependencies are ok and the only way to fix this problem is by having a testing distribution for unreleased architectures, then please reassign this bug to the ftp.debian.org virtual package. Thanks.
Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
On Mon, 21 Oct 2002, Ben Collins wrote: If you do not consider this a problem in libc, please reassign this to the ftp.debian.org package so that they create a testing distribution for all unreleased architectures, one that does not remove old packages until the new ones become installable. Unstable is a freaking moving target. Don't file bugs just because things don't stay in sync. That's ignorant. Exactly what part of please reassign to ftp.debian.org didn't you understand? 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?
Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
On Mon, Oct 21, 2002 at 11:15:37PM +0200, Santiago Vila wrote: On Mon, 21 Oct 2002, Ben Collins wrote: If you do not consider this a problem in libc, please reassign this to the ftp.debian.org package so that they create a testing distribution for all unreleased architectures, one that does not remove old packages until the new ones become installable. Unstable is a freaking moving target. Don't file bugs just because things don't stay in sync. That's ignorant. Exactly what part of please reassign to ftp.debian.org didn't you understand? 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. So reduce your FUD. I am not against locales, or the users of it. Quite the contrary. The mechanism exists so that locales remains in a working state. 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) 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. 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. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/
Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
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.
Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
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/
Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
Package: locales The dependency of locales on glibc-$DEBVERSION is harmful for non-released architectures like the Hurd, since the only locales package which exists (since there is not a testing disrtibution) becomes uninstallable until the glibc package is recompiled. Such dependency should be on glibc-$VERSION at most. The reason glibc-$DEBVERSION was required in the past was that, at some point, there were incompatible locales and libc packages having the same VERSION but different DEBVERSION numbers. This was because the maintainer was introducing new code from CVS without changing the VERSION, which may be considered as a bad practice. So, I request that the dependency is changed again to a non-debversioned one (like glibc-$VERSION) and the maintainer refrains from making incompatible changes without changing $VERSION as well. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
Package: locales The dependency of locales on glibc-$DEBVERSION is harmful for non-released architectures like the Hurd, since the only locales package which exists (since there is not a testing disrtibution) becomes uninstallable until the glibc package is recompiled. Such dependency should be on glibc-$VERSION at most. The reason glibc-$DEBVERSION was required in the past was that, at some point, there were incompatible locales and libc packages having the same VERSION but different DEBVERSION numbers. This was because the maintainer was introducing new code from CVS without changing the VERSION, which may be considered as a bad practice. So, I request that the dependency is changed again to a non-debversioned one (like glibc-$VERSION) and the maintainer refrains from making incompatible changes without changing $VERSION as well. Thanks.
