Project

General

Profile

Actions

Bug #12896

closed

QT5 manifest needs mediated symlinks

Added by Gary Mills about 3 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
OI-Userland
Target version:
Start date:
Due date:
% Done:

50%

Estimated time:
Difficulty:
Medium
Tags:

Description

The qt4 manifest has many mediated symbolic links, obviously in anticipation of a version upgrade. According to the qt web site, version 4 is obsolete. However, the qt5 manifest has no mediated symlinks, making a version upgrade incomplete on OI.

I'm in the process of developing a new manifest for qt5, one that includes the same mediated symlinks as qt4. All of the new symlinks will point to 64-bit binaries. I'll attach the new manifest to this bug report once development is complete.

In order to accommodate the change to the manifest, it will be necessary to adjust COMPONENT_REVISION in the Makefile . It will probably have to be set to 11, as it's 10 in the latest package.


Files

qt5.p5m.diff (5.12 KB) qt5.p5m.diff Gary Mills, 2020-06-27 07:44 PM
Makefile.diff (361 Bytes) Makefile.diff Gary Mills, 2020-06-27 07:44 PM

Related issues

Related to OpenIndiana Distribution - Bug #12876: Qt5 package is incompleteRejected

Actions
Actions #1

Updated by Gary Mills about 3 years ago

  • Related to Bug #12876: Qt5 package is incomplete added
Actions #2

Updated by Aurélien Larcher about 3 years ago

Probably you should not spend too much time on this and only deliver symlinks for Qt5.
I do not think it makes sense to mediate the obsolete Qt4 and the current Qt5 which are incompatible.
Thank you for looking into this.

Actions #3

Updated by Aurélien Larcher about 3 years ago

Back when I packaged Qt5 some packages in oi-userland relied on Qt4 being default in /usr/bin.

Had I mediated symlinks for Qt5 I would have broken the build of these packages whenever the mediator was switched, so really this was not an overlook nor an incomplete packaging, this was deliberate: Qt4 and Qt5 being specifically required by some packages, being incompatible, and providing a different set of binaries they should not have been mediated.
Indicating which Qt to use was as simple as pre-pending the path.

Mow I agree that Qt4 being obsolete we can have Qt5 as default.
But please make sure that nothing uses Qt4 anymore, I do not want to spend time fixing this type of breakage.

Actions #4

Updated by giahung 1997tn about 3 years ago

Aurélien Larcher wrote:

Back when I packaged Qt5 some packages in oi-userland relied on Qt4 being default in /usr/bin.

Had I mediated symlinks for Qt5 I would have broken the build of these packages whenever the mediator was switched, so really this was not an overlook nor an incomplete packaging, this was deliberate: Qt4 and Qt5 being specifically required by some packages, being incompatible, and providing a different set of binaries they should not have been mediated.
Indicating which Qt to use was as simple as pre-pending the path.

Mow I agree that Qt4 being obsolete we can have Qt5 as default.
But please make sure that nothing uses Qt4 anymore, I do not want to spend time fixing this type of breakage.

Then remove both of the Qts and Qt based packages from your system. Since your Qt 5 is also desperately outdated and also broken and incomplete since components like QtWebEngine not yet ported and there seemed to be not many or no Qt 5 based software on the repo at all. Why doing something that you don't have interest? Just remove them is the best. You don't have to care about the maintenance burdens. Let's make OI as GTK only like many Linux distro. Done.

This approach is only true for the base system. In the name of compatibility you have kept too much of sh*t on it. I'm very sad when Unleased OS announced that they are closing. I definitely prefer their way: modernizing the toolchain, remove everything proprietary and unneeded anymore, ditch Sun's ld and switch to ld.bfd completely, whole system as x86_64 only, remove anything x86 left... Too sad!

https://www.unleashed-os.org/releases/1.4/notes.txt

Actions #5

Updated by Aurélien Larcher about 3 years ago

We need some Qt5 version for VirtualBox, VLC, LibreCAD (which btw was only migrated to Qt5 a few weeks ago).

I actually already worked on packaging Qt 5.15 but again, this is purely voluntary work done in my spare time like other contributors here and unfortunately (again) sometimes life has other priorities.
If a package needs to be added or updated, the best way is to work on it and ask for help :)

Actions #6

Updated by Aurélien Larcher about 3 years ago

We actually hosted some Unleashed bits and I also found their approach interesting, too bad they had other priorities, I wish we could have collaborated more.

Do you really think we kept all the old stuff just for fun?

We spent two years migrating away from old consolidations and we are still modernizing the system incrementally.
It takes time when people only contribute on a voluntary basis during their evenings and week-ends.

Actions #7

Updated by Aurélien Larcher about 3 years ago

Removing 32-bit binaries takes time and we have already been working on it for quite some time.
It takes time when you need to avoid breaking stuff in a userland of 4000 packages and care for users.
It is easier when you have less than 100 packages and zero users.

Actions #8

Updated by giahung 1997tn about 3 years ago

Aurélien Larcher wrote:

We need some Qt5 version for VirtualBox, VLC, LibreCAD (which btw was only migrated to Qt5 a few weeks ago).

I actually already worked on packaging Qt 5.15 but again, this is purely voluntary work done in my spare time like other contributors here and unfortunately (again) sometimes life has other priorities.
If a package needs to be added or updated, the best way is to work on it and ask for help :)

Hi. In case of you are also the VLC maintainer, then it's not work at all for me. Can't play even a mp3.

I forgot about VBox. If it's so then what about rename the current qt5 package from qt5 to libqt5, so users could clearly know that it's just the library but not the whole sdk itself?

Actions #9

Updated by Gary Mills about 3 years ago

I've now completed development of the new manifest. I'm attaching diff files for the manifest (qt5.p5m) and the Makefile (Makefile) to this bug report. Thanks to all for the suggestions and warnings. I believe I've addressed them all in my changes to the manifest, but further comments are welcome.

The following example, from the pkg(5) man page, shows the use of a mediated link:

       A mediator is a name that represents a set of related symbolic or hard
       links. If two or more link actions have the same path and mediator
       name, the user or the package system selects the link target based on
       version, implementation, or priority. See "Link Actions" for
       information about mediator attributes.

       The following example shows two different instances of a mediator named
       java where the link choices are between versions. These two link
       actions would appear in two different packages.

         link mediator=java mediator-version=1.6 path=usr/java target=jdk/jdk1.6.0_31
         link mediator=java mediator-version=1.7 path=usr/java target=jdk/jdk1.7.0_02
       See the set-mediator subcommand in the pkg(1) man page for information
       about how to select the version you want for this link path. To have a
       choice of versions, both packages must be installed.

This man page implies that both qt4 and qt5 packages can be installed, but that only one will be active through the mediated symlinks.

I've only added mediated symlinks to the qt5 manifest. I've made no deletions. In particular, I have not removed the 32-bit binaries. I've made no alterations. I've made no version upgrades: these can be done later. The changes should be safe for qt4 applications, unless they use mediated links. They will be safe for existing qt5 applications.

Below is a test install of the new qt5 package:

# pkg install -nv /library/qt5@5.8.0,5.11-2020.0.1.11
           Packages to install:       1
            Packages to change:       1
           Mediators to change:       1
     Estimated space available: 6.08 GB
Estimated space to be consumed: 1.48 GB
       Create boot environment:      No
Create backup boot environment:     Yes
          Rebuild boot archive:      No

Changed mediators:
  mediator qt:
           version: 4.8 (system default) -> 5.8 (system default)

Changed packages:
openindiana.org
  library/qt4
    4.8.7-2020.0.1.8
userland
  library/qt5
    None -> 5.8.0-2020.0.1.11

Note that the install of the qt5 package changes the mediator version, and removes the mediated links for the qt4 package. All of them will point to binaries in the qt5 package now.

I found that I could remove the qt4 package with no complaints from the pkg command. There are some dependancies on this package (desktop/keepassx, desktop/librecad, system/storage/testdisk), but I must have none of them installed. There are some dependancies on the qt5 package (desktop/fbreader, media/vlc, system/virtualbox), but I must also have none of them installed. In any case, the qt5 applications will be safe as nothing that they might use has been changed.

Actions #10

Updated by Gary Mills almost 3 years ago

I've just finished creating a Github PR for this bug report. It's PR number 6144 .

This PR does not change or delete existing file actions in the manifest. It only adds mediated links. The change does solve some problems, without introducing new ones.

Actions #11

Updated by Gary Mills almost 3 years ago

  • Status changed from New to Closed

Integrated and will be closed.

Actions

Also available in: Atom PDF