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.
