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