Rename xf86-prefixed packages to xlibre

[callmetango]

Describe the feature

We should rename all packages in the x11-drivers category prefixed by xf86-... to xlibre-.... We should add a blocker as of ! x11-drivers/xf86- to every package's DEPEND to mark their incompatibilty with the x11-drivers/xf86-... ones.

It should be done because

In the early days of this overlay, there was an attempt to do so but we didn't. Now that the dust has settled, it is clear that the packages in the x11-drivers category of this overlay really are XLibre API- and ABI-compatible only and decoupled from anything X.org or Xfree86. Still using the xf86- prefix is a bit misleading as shown here for example.

What are the alternatives?

Leave things as they are and maybe confuse users of the overlay.

Additional context

No response

Extra fields

• I have checked the existing issues
• I have read the Contributing Guidelines
• I'd like to work on this issue

[callmetango]

@stefan11111 What do you think?

[callmetango]

Related-to: #42

[stefan11111]

@callmetango
I don't think we should change the name of the ebuilds like this, unless we also change the name of the drivers.
I lean more towards #46 , where we could create versioned ebuilds,
but only for those drivers that would otherwise break.
Adding a versioned ebuild with keywords for live code is a hack.
I do it in my overlay because I know what I'm installing, but we should keep hacks like this to a minimum here.
Other that the intel driver, is there another driver from ::gentoo that doesn't compile with xlibre, but works
when built from ::xlibre?

[callmetango]

@stefan11111

I don't think we should change the name of the ebuilds like this, unless we also change the name of the drivers.
[...]
Other that the intel driver, is there another driver from ::gentoo that doesn't compile with xlibre, but works
when built from ::xlibre?

@metux A while ago you said in X11Libre/xserver#210 (comment):

Not sure, but maybe it would be cleaner to call the packages with xlibre prefix.
Also make sure that xlibre server is using the xlibre drivers (not the xorg ones - those will break with their recent commits).

@metux What do you think about renaming the Gentoo ebuids from xf86-... to xlibre-...?

[metux]

@metux What do you think about renaming the Gentoo ebuids from xf86-... to xlibre-...?

I'm leaving this to the gentoo-ports maintainer, but my personal feeling is that having our own prefix is the better way in the long run (theoretically it should be possible to have both xorg and xlibre installed at the same time)

[callmetango]

@metux

I'm leaving this to the gentoo-ports maintainer, but my personal feeling is that having our own prefix is the better way in the long run (theoretically it should be possible to have both xorg and xlibre installed at the same time)

Thank you and I also think that it should be possible to have Xorg and XLibre installed at the same time.

Another question: Are there and - even more important - will there be any changes which lead to imcompatibilities between the Xorg provided drivers and the XLibre Xserver?

[stefan11111]

@metux

I'm leaving this to the gentoo-ports maintainer, but my personal feeling is that having our own prefix is the better way in the long run (theoretically it should be possible to have both xorg and xlibre installed at the same time)

Thank you and I also think that it should be possible to have Xorg and XLibre installed at the same time.

It is possible to run both Xorg and Xlibre at the same time, but it's not pretty.
Xorg and Xlibre don't just come with the X server, they also come with headers that are needed for drivers.

For testing, I have 2 Xorg servers, one built with udev, the other without, along with drivers for them built against them. I keep the drivers is a separate path, to not conflict with the Xlibre drivers.

As such, it is possible to do this, but it's definitely not 'plug and play'.

The main problem it the headers. It isn't hard to build the 2 X servers and put everything in separate locations,
e.g. like the old /usr/X11R6 installs. The problem is, it you then want to build something that uses these headers, how does it know which headers to use?

Another question: Are there and - even more important - will there be any changes which lead to imcompatibilities between the Xorg provided drivers and the XLibre Xserver?

There already are such changes, though just for the intel ddx driver, afaik.
Exported structs in the X server headers change.
This can cause existing drivers either not to build (api incompatibility),
or already built drivers to not work properly (abi incompatibility).
I try to keep compatibility for both of these, but as things change in the X server code,
some drivers from ::gentoo might break.

[callmetango]

The main problem it the headers. It isn't hard to build the 2 X servers and put everything in separate locations, e.g. like the old /usr/X11R6 installs. The problem is, it you then want to build something that uses these headers, how does it know which headers to use?

I understand.

There already are such changes, though just for the intel ddx driver, afaik.
Exported structs in the X server headers change.
This can cause existing drivers either not to build (api incompatibility),
or already built drivers to not work properly (abi incompatibility).
I try to keep compatibility for both of these, but as things change in the X server code, some drivers from ::gentoo might break.

I asked @metux this question and he replied in X11Libre/xserver#436 (comment):

Will the Xorg device dependent drivers (DDX) work with XLibre? E.g. which and where to choose from?

no

This is also stated in Device Dependent X (DDX) Drivers - Compatibility of XLibre · X11Libre/xserver Wiki. So I am very much in favor of changing the prefix. from xf86- to xlibre- to avoid confusion and make clear that these drivers are not the same nor swappable anymore.

[v-evets]

This just screwed me, as ::gentoo bumped x11-drivers/xf86-video-amdgpu to 25.0.0 (vs. 23.0.0.6 in ::xlibre), and I didn't have conflicting packages explicitly masked.
Any progress on a decision here? It'd be kinda nice to not have this kind of problem in future...

[stefan11111]

@v-evets Can you try masking the gentoo xf86 drivers?

[v-evets]

I have now, and it works as expected. It's kind of an ugly solution though, and not mentioned in the instructions.
That wasn't a problem report so much as "here's an example of why we need this, are we doing it or what?"

If ::xlibre packages are incompatible with ::gentoo packages, that should be reflected in naming and dependencies, not reliant on manual masking.

[M95D]

Portage has a mechanism of triggering rebuilds for dependent packages. I don't know how it works, but forcing a rebuild of drivers woudn't solve the problem?