Overview
Request 620406 accepted
- Obsolete protocol packages by their corresponding old package names, not by
their pkconfig(...) provides. Additionally move the obsoletes to the -devel
package to take effect.
- Create package xorgproto with initial version 2018.4:
This package contains all previously split up xorg protocol headers in one
package (again!). Additionally this package contains two new protocol
versions required by the upcoming XServer 1.20:
+ dri3proto version 1.2
+ randrproto version 1.6
- Obsolete the old *prot packages by using the actual protocol version to keep
this package compatible with the old versioning scheme.
- "Prefer: xorgproto-devel" in the project config is required to prefer it for
now
If things with
"Prefer: xorgproto-devel"
in the project config works out in factory, I'll make delete requests
for *proto packages.
+Obsoletes: pkgconfig(applewmproto) <= 1.4.2 +Obsoletes: pkgconfig(bigreqsproto) <= 1.1.2 +Obsoletes: pkgconfig(compositeproto) <= 0.4.2 +Obsoletes: pkgconfig(damageproto) <= 1.2.1 +Obsoletes: pkgconfig(dmxproto) <= 2.3.1 +Obsoletes: pkgconfig(dri2proto) <= 2.8 +Obsoletes: pkgconfig(dri3proto) <= 1.2
This does not work as you might expect: obsoleting provided symbols does NOT trigger other packages with said providers to be removed.
FTR, I tested this with simple packages:
A.spec:
Name: A Provides: B
C.spec:
Name: C Obsoletes: B
installing A, then 'upgrading to C' does not remove A
Mh, i can't remember this being a problem when creating the Obsoletes in question, yet this, what i would call "pkgconfig resolve of obsoletes at runtime", could be a nice addition to the corresponding infrastructure ?rpm!?. But here it is indeed not needed, we can just Obsolete the packages directly!
I doubt RPM will ever do obsoletion of non-package names (and this never worked so far)
So changing to obsoleting package names is mandatory
Will there also be an update of xproto? or is xproto supposed to be removed in the end? (then please send a DR, so I can group it together with xorgproto in the staging group)
xproto is included in xorgproto, so that package can be removed, as all the other packages xorgproto supersedes (the new obsoletes list):
xorg-x11-proto-devel bigreqsproto-devel <= 1.1.2 compositeproto-devel <= 0.4.2 damageproto-devel <= 1.2.1 dmxproto-devel <= 2.3.1 dri2proto-devel <= 2.8 dri3proto-devel <= 1.2 fixesproto-devel <= 5.0 fontsproto-devel <= 2.1.3 glproto-devel <= 1.4.17 inputproto-devel <= 2.3.2 kbproto-devel <= 1.0.7 presentproto-devel <= 1.2 randrproto-devel <= 1.6.0 recordproto-devel <= 1.14.2 renderproto-devel <= 0.11.1 resourceproto-devel <= 1.2.0 scrnsaverproto-devel <= 1.2.2 trapproto-devel <= 3.4.3 videoproto-devel <= 2.3.3 windowswmproto-devel <= 1.0.4 xcmiscproto-devel <= 1.2.2 xextproto-devel <= 7.3.0 xf86bigfontproto-devel <= 1.2.0 xf86dgaproto-devel <= 2.1 xf86driproto-devel <= 2.1.1 xf86miscproto-devel <= 0.9.3 xf86vidmodeproto-devel <= 2.3.1 xineramaproto-devel <= 1.2.1 xproto-devel <= 7.0.32 xproxymngproto-devel <= 1.0.3
Request History
sndirsch created request
- Obsolete protocol packages by their corresponding old package names, not by
their pkconfig(...) provides. Additionally move the obsoletes to the -devel
package to take effect.
- Create package xorgproto with initial version 2018.4:
This package contains all previously split up xorg protocol headers in one
package (again!). Additionally this package contains two new protocol
versions required by the upcoming XServer 1.20:
+ dri3proto version 1.2
+ randrproto version 1.6
- Obsolete the old *prot packages by using the actual protocol version to keep
this package compatible with the old versioning scheme.
- "Prefer: xorgproto-devel" in the project config is required to prefer it for
now
If things with
"Prefer: xorgproto-devel"
in the project config works out in factory, I'll make delete requests
for *proto packages.
staging-bot set openSUSE:Factory:Staging:L as a staging project
Being evaluated by staging project "openSUSE:Factory:Staging:L"
staging-bot accepted review
Picked openSUSE:Factory:Staging:L
licensedigger accepted review
ok
factory-auto added opensuse-review-team as a reviewer
Please review sources
factory-auto added repo-checker as a reviewer
Please review build success
factory-auto accepted review
Check script succeeded
dimstar accepted review
dimstar added dimstar as a reviewer
accept block: Staging has an extra Prefer: xorgproto-devel, which must not be used in the distro in the end
repo-checker accepted review
cycle and install check passed
repo-checker accepted review
skip
dimstar accepted review
dimstar_suse accepted review
ready to accept
dimstar_suse approved review
ready to accept
dimstar_suse accepted request
Accept to openSUSE:Factory
We get:
have choice for pkgconfig(xextproto) >= 7.0.99.1: xextproto-devel xorgproto-develI can work around this using prjconf settings, BUT the clean thing would be for xextproto to no longer provide this devel package
I don't understand what you mean exactly here. :-(
I believe you didn't get at all, what I wrote from the beginning. :-(
If things with
"Prefer: xorgproto-devel"
in the project config works out in factory, I'll make delete requests for *proto packages. [-]
relying on 'Prefer' for such a case is possible, but is just offloading hacks onto OBs. xorgproto-devel obsoletes xextproto-devel, so in fact there is no reason why xextproto-devel is even provided anymore. Why not clean up the stuff instead of relying on OBS swapping packages around?
Because I want to see how many package builds are failing before I do the final switch. Otherwise I may need to fix hundreds of packages in very short time giving me extra pressure.
sure - everybody prefers to offload their work to me - strangely enough, this does not scale.
I can give you that switch in the staging, but I will not accept the staging until this is cleaned up; You're free to setup any test repo at any moment before you submit stuff into the Distributions.
for now I added
to Staging:L (and a review block, so it can't be accepted)
Thanks. Just checked https://build.opensuse.org/project/monitor/openSUSE:Factory:Staging:L. Zero build failures. This looks to good to be true. Therefore I'm wondering, whether we need a rebuild here before I can be sure, that no changes in other packages are needed here. I mean before I file delete requests for about 40 proto packages ...
Filing the delete requests would be the right way to go: the staging is there to simulate the end state, and not some random intermediate state.
As for rebuild: the stagings all have automatic rebuild (unlike openSUSE:Factory, where we need to tune for timing); but I'll to a rebase of :L again against the current state of openSUSE:factory - and trigger a full rebuild to be sure all is ok
Ok. Delete requests filed for all affected proto packages. SR #623407-623439
@dimstar With that you can remove "Prefer: xorgproto-devel" from prjconf of Staging project again.
nothing provides pkgconfig(printproto)This one seems to have a delete request, bot xorgproto is not stepping in there
Furthermore, the amdgpu video driver fails with:
conflict for providers of pkgconfig(xproto), (provider xorgproto-devel obsoletes damageproto-devel)This is because the .spec file contains a BuildRequires: damageproto-devel, which is obsoleted by xorgproto-devel, BUT not provided (as a result obs can't find a solution with only xorgproto-devel; the obsoileted packages are also to be provided)
Ermm - only to be provided of course if the functionality is provided (I guess in most cases this is true, just that the pkgconfig() symbols are provided and used in most cases)
Fixes this now in xf86-video-amdgpu -> SR#622483