Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
At Mon, 21 Oct 2002 12:17:50 +0200 (CEST),
Santiago Vila 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.
How many uninstallable period do you have?
> 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 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?
> > > 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.
No, localedata in 'locales' and locale handling code in 'libc6'
should be strongly connected. 'locales' is splitted from 'libc6'
because some users does not want to install localedata (they don't
use locale, imagine embedded device which has only small storage).
Your idea makes the size of libc6 package double.
You can search the discussion at debian-devel mailing list for a
year ago or so.
-- gotom
Reply to: