[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 (<<, xlib6 (<<, xlib6g-dev (<<
Depends: xfree86-common, libc6 (>= 2.1.2)
Conflicts: xlib, xlib6 (<<, xlib6g-dev (<<
Package: xlibs
Version: 4.0.1-4
Replaces: xlib, xbase (<<, xlib6 (<<, 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 (<<, 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 (<<, elf-x11r6lib, xlib
Depends: xlib6g (>=, libc5 (>= 5.4.0-0)
Conflicts: elf-x11r6lib, xlib

        The point of contention seems to be these following
Conflicts: xlib6 (<<
Replaces: xlib6 (<<

        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 ({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
 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 (<<
 xlib6 (=, xlib6 (=, xlib6 (=,
 xlib6 (=, xlib6 (=, xlib6 (=

        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

        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

        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 (<<
Conflicts: xlib6 (<<

        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.

 Would be nice if dpkg supported somthing like this:
Replaces: xlib6 (=~, xlib6 (<<
Conflicts: xlib6 (=~, xlib6 (<<
 where =~ says that the version must match the specified string, but
 may contain trailing elements (a poor man's wild card)

Reply to: