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.
Reply to: