Re: Bug#34672: Installing xlib6g removed xlib6.
At this point, Manoj has made a suggestion (in the bug db for #34672)
that seems to have gotten both Santiago and Branden to agree on the
resolution of that particular bug. I'm going to quote its body here.
[The rest of this message is Manoj's, from that context]:
May I ask for clarification on the original bug report? And
perhaps offer an equitable solution? I see the following conflicts
and replaces in a recent packages:
======================================================================
Package: xlib6g
Version: 3.3.6-10
Replaces: xlib, xbase (<< 3.3.2.3a-2), xlib6 (<< 3.3.2.3a-8), xlib6g-dev (<< 3.3.2.3a-2)
Depends: xfree86-common, libc6 (>= 2.1.2)
Conflicts: xlib, xlib6 (<< 3.3.2.3a-8), xlib6g-dev (<< 3.3.2.3a-2)
======================================================================
======================================================================
Package: xlibs
Version: 4.0.1-4
Replaces: xlib, xbase (<< 3.3.2.3a-2), xlib6 (<< 3.3.2.3a-8), xbase-clients (<< 4.0), xlib6g (<< 4.0), xlib6g-dev (<< 4.0), xpm4g, fvwm-common, xcontrib
Provides: libxpm4
Depends: xfree86-common (>= 4.0.1), libc6 (>= 2.1.94)
Conflicts: xlib, xlib6 (<< 3.3.2.3a-8), xlib6g (<< 4.0), xlib6g-dev (<< 4.0), xpm4g, libxfont-xtt
======================================================================
Package: xlib6
Version: 3.3.6-10/3.3.6-13/3.3.6-14
Replaces: xbase (<< 3.3.2.3a-2), elf-x11r6lib, xlib
Depends: xlib6g (>= 3.3.2.3a-8), libc5 (>= 5.4.0-0)
Conflicts: elf-x11r6lib, xlib
======================================================================
The point of contention seems to be these following
relationships:
Conflicts: xlib6 (<< 3.3.2.3a-8)
Replaces: xlib6 (<< 3.3.2.3a-8)
Now, I am given to understand that slink has version
xlib6g_3.3.2.3a-11, and thus is not a factor.
The basic problem appears to be that there were a few versions
released (3.3.2.3a-{2,3,4,5,6,7}) where the conflict occurred, but
there is an older version with no conflict (xlib63.3.2.3-2). And that
is the version in Hamm. The point to consider is that these 3.3.2.3a
versions that require a conflicts were pre-release unstable slink;
released hamm and released slink are not in conflict.
This bug report proposed a (quite ugly) solution:
Conflicts: xlib, xlib6 (<< 3.3-5), xlib6g-dev (<< 3.3.2.3a-2)
xlib6 (= 3.3.2.3a-2), xlib6 (= 3.3.2.3a-3), xlib6 (= 3.3.2.3a-4),
xlib6 (= 3.3.2.3a-5), xlib6 (= 3.3.2.3a-6), xlib6 (= 3.3.2.3a-7)
I can understand the problem with this solution is a
reluctance to carry forward this massive conflict/replace line (since
there are 6 terms that deal with xlib6, as opposed to just
one).
Is this a fair statement of the dispute?
It boils down to whether our commitment to smooth upgrades is
worth packages carrying around convoluted conflict relationships. I
think we should be committed to smooth upgrades from previous
*released* versions, and from the most recent unstable to the
current release/unstable (and not necesarily from older unstable
versions to the current versions [I'll expand on this if it is
needed]).
I suggest that we drop support for unstable slink upgrading to
the current, but support smooth upgrades from released Hamm and
Slink, which can be achieved by these relationships:
Replaces: xlib6 (<< 3.3.2.3-2)
Conflicts: xlib6 (<< 3.3.2.3-2)
Anyone running unstable slink should upgrade to slink, and ten
to potato/woody unstable. People running released hamm and slink can
upgrade to woody, even, and not automatically have xlib6 removed.
Is this suggestion acceptable to both parties? If so, the
tech-ctte can use this as a basis for a ruling.
manoj
Would be nice if dpkg supported somthing like this:
Replaces: xlib6 (=~ 3.3.2.3a), xlib6 (<< 3.3.2.3)
Conflicts: xlib6 (=~ 3.3.2.3a), xlib6 (<< 3.3.2.3)
where =~ says that the version must match the specified string, but
may contain trailing elements (a poor man's wild card)
Reply to: