Hi Matthew,
> I can't see anything else obvious, I shall email debian-x and ask
> whether it should be maintained in the XSF repositories.
Excellent; I saw your post and have incorporated the following changes:
* Rename source package libdrm-snapshot => drm-snapshot.
* Remove X.Org "endorsements" from xserver-xorg-video-nouveau package
description.
So as I see it, the two issues that remain are:
1. libdrm shared-object binary name
===================================
> > However, I seem to have been misinformed about how the
> > Replaces/Conflicts/Provides trick works (or am doing something silly)
> > as my attempts to construct a package that can replace the libdrm2
> > package whilst still providing it were unsuccessful - attempting to
> > install the resulting package kept trying to remove X.Org. (Currently,
> > each package currently just "Replaces:" its non-snapshot counterpart.)
>
> I believe you need all three. Conflicts causes the other one to be
> removed, Provides causes dependencies on all the others to be satisfied.
Hm, I tried again.. When using all three, ie.:
Package: libdrm-snapshot2
[...]
Replaces: libdrm2 (<< 2.3.1~git+20080530+6e8a2cf-1)
Conflicts: libdrm2 (<< 2.3.1~git+20080530+6e8a2cf-1)
Provides: libdrm2
.. and testing the upgrade from unstable's libdrm2, I get:
http://chris-lamb.co.uk/b/libdrm-snapshot-dpkg.txt
Using --auto-deconfigure does not help, and nor does placing the files in a
repository. Are we certain that Replaces/Conflicts/Provides works with
non-virtual packages?
Julien's reply to your debian-x mail suggested:
> if you provide libdrm.so.2 you'll have to conflict with the libdrm2
> package from unstable, and then the driver won't be installable together
> with the x server? If someone can check that the only symbols missing
> from the snapshot version of the lib are TTM-related, maybe it'd be better
> to just call it libdrm2? (I know I've said the opposite before, but I
> thought the removed symbols were being used.)
Hm, what do you think? The snapshot packages would never be in unstable so
there is not a namespace conflict, but it would rob the existing libdrm
source package of control over experimental. However, according to Julien
on IRC, libdrm in experimental was only used for very new versions rather
than to test transitions, etc.
(On the other hand, having a completely different package name gives a nice
seperation; no accidental installations of the bleeding-edge code.)
2. Maintainer/Uploaders field
=============================
> At the very least it should be maintained in a shared VCS and I should
> be added as an uploader.
Agree 100%. As the owner of the ITP, I defer this decision to you. I am
perfectly happy with it being in the XSF repositories, but I do not have
commit access there. Do you happen to know the procedure for joining?
For completeness, I have updated the packages:
http://chris-lamb.co.uk/debian/drm-snapshot_2.3.1~git%2b20080530%2b6e8a2cf-1.dsc
http://chris-lamb.co.uk/debian/xserver-xorg-video-nouveau_0.0.10~git%2b20080601%2be034616-1.dsc
Regards,
--
Chris Lamb, UK chris@chris-lamb.co.uk
GPG: 0x634F9A20
Attachment:
signature.asc
Description: PGP signature