On Tue, Jun 29, 2010 at 00:04:19 +0200, David Kalnischkies wrote:
> Hello,
>
> 2010/6/28 Julien Cristau <jcristau@debian.org>:
> > ever since etch or so, Xorg upgrades have been a bit of a pain as
> > apt/aptitude decide to uninstall driver packages instead of upgrading
> > them.
>
> ( If you want to be sure that aptitude is in the loop you want to write
> to aptitude@packages.debian.org too, but we are talking here based
> on the great upgrade test from Petter Reinholdtsen "just" about the
> current behavior of APT, doesn't we? )
>
Partly based on Petter's tests, and partly based on experience from
upgrade reports for lenny.
As far as I know apt and aptitude both have the same problem with this
upgrade path, so adding aptitude@pdo in the loop. aptitude people, this
thread started at http://lists.debian.org/deity/2010/06/msg00088.html.
> I haven't found the real cause for this problem, but for the time being
> you can add to the xserver-xorg-video-all package the following line:
> >>>>>
> Breaks: xserver-xorg-video-cyrix, xserver-xorg-video-dummy,
> xserver-xorg-video-glint, xserver-xorg-video-i810,
> xserver-xorg-video-imstt, xserver-xorg-video-nsc,
> xserver-xorg-video-radeonhd, xserver-xorg-video-tga,
> xserver-xorg-video-v4l, xserver-xorg-video-vga, xserver-xorg-video-via
> <<<<<
> (a list of all packages xserver-xorg-video-all depended on in lenny but
> no longer in squeeze). You might want to add versions to these breaks,
> also a different package is maybe a better fit for this breaks line,
> but at least in my test this caused the xorg upgrade problem to disappear.
>
Ah, that sounds doable, thanks. (Probably with versioned Breaks in
xserver-xorg-core.)
> > The current situation looks like this:
> >
> > Package: xserver-xorg
> > Depends: xserver-xorg-core, xserver-xorg-video-all | xserver-xorg-video-${abi}
> >
> > Package: xserver-xorg-core
> > Depends: xserver-xorg
> > Conflicts: xserver-xorg-video-${oldabi}
> >
> > Package: xserver-xorg-video-foo
> > Provides: xserver-xorg-video-${abi}
> > Depends: xserver-xorg-core
>
> The conflicts is a breaks in current unstable, isn't it?
Yeah I changed it to a breaks recently.
> Packages like x11-common seems to have a lot of conflicts.
> Are all of them - not only in this specific package - really needed or
> would be Breaks enough? (see also the fresh policy version 3.9.0)
Conflicts was needed for x11-common, because of the move of
/usr/X11R6/bin from a directory to a symlink in etch, so packages
installing files in that directory needed to be upgraded or removed
before x11-common could be unpacked. They should hopefully not hurt too
much nowadays since all those conflicts are on very old packages, but
I dropped them earlier today, will be in the next upload.
http://git.debian.org/?p=pkg-xorg/debian/xorg.git;a=commitdiff;h=1d025ea416513e628859c51279d06741e00e7a0c
Which other conflicts are you concerned about?
> Also, xserver-xorg and xserver-xorg-core forming a dependency loop
> in your snippet.
>
Yes, that's #362313. I believe xserver-xorg-core can drop its
dependency on xserver-xorg, but iirc last time this happened there was
some complaint (#392295).
> > For squeeze I'm trying to get to something like this:
> >
> > Package: xserver-xorg
> > Depends: xserver-xorg-core, xserver-xorg-video-all | xorg-driver-video
> >
> > Package: xserver-xorg-core
> > Provides: xorg-video-abi-${abi}
> >
> > Package: xserver-xorg-video-foo
> > Depends: xorg-video-abi-${abi}
> > Provides: xorg-driver-video
>
> Looks much better on first glance. :)
> But why the Depends on xserver-xorg-video-all ?
I want to get xserver-xorg-video-all installed by default, but allow
people to shoot themselves in the foot (by removing the drivers they
don't use) if they so choose. Having just a recommends on -all didn't
quite feel strong enough.
> I assume that all packages xserver-xorg-video-all depends on will
> provide xorg-driver-video so you depend on (A & B & …) | (A | B | …).
> While apt currently chooses always the first option at first if it needs
> to install something it is not guaranteed that it will do this forever or
> that any other $packagemanager will always choose the A & B & … path
>
It seems like both apt and aptitude put a strong preference for the
first alternative in any case, so this seemed to work so far (except on
upgrades, where both of them would remove a set of drivers).
Thanks for the help,
Julien
Attachment:
signature.asc
Description: Digital signature