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