pacstall-programs
pacstall-programs copied to clipboard
pacstall
upd(goverlay):`1.0` -> `1.1.1`
I have canceled my branch.. it has canceled all my PR ...
I don't understand the uninstall error. I suppose the problem is pacdeps should be makepacdeps (but doesn't exists) .
Here the control file generated :
Depends: mangohud, fpc-laz, fpc-src, lazarus-project, libqt6pas6
Package: goverlay
Version: 1.1.1-pacstall1
Architecture: amd64
Section: Pacstall
Priority: optional
Build-Depends: git, libglu1-mesa-dev, qt6-base-dev
Conflicts: goverlay-bin
Replace: goverlay-bin
Maintainer: Xdavius <[email protected]>
Description: A GUI to help manage Vulkan/OpenGL overlays
Installed-Size: 4193
I have canceled my branch.. it has canceled all my PR ...
I don't understand the uninstall error. I suppose the problem is pacdeps should be makepacdeps (but doesn't exists) .
This seems to be an issue on the CI end, not yours. It has a flaw of removing pacstall packages in alphabetical order, instead of dependency order, meaning if an alphabetically higher up dependency of a package is removed for a parent package, that package will come down too, with it, and then be unable to be removed later, because it was already removed before.
Basically, in this case, fpc-laz-deb is being removed before goverlay, which is triggering goverlay to be removed at the same time:
The following packages will be REMOVED:
fpc-laz goverlay lazarus-project
which then results in:
Removing fpc-src (3.2.2) ...
Running pacstall -R for goverlay...
[*] WARNING: Reading input from pipe
[*] WARNING: Prompts are disabled
[!] ERROR: goverlay is not installed
not something for you to be concerned about. However, can you please explain why both goverlay and goverlay-bin exist? In their current state, they are essentially identical.
Hi. Thank you for replying.
In fact, I have tested on my side. Uninstalling fpc-src uninstall goverlay. But I don't want this comportement... Because it's not an execution dependency, just a build one.
If you know the way to avoid this problem... (Not tested to declare empty depends, I don't know if it will do the trick...)
For your question, goverlay-bin is the binary provided by upstream. At this moment, it is still in qt5 version 1.0.
This one is qt6 and rebuilt from source. The distributions aren't totally compatible with it, making the use of qt6ct for exemple for the theme.
Originally, goverlay-bin was named goverlay, but was a bin. So I have updated the name of the package.
And goverlay is from source as it must be.
I will continue to maintain both, but -bin will be left on 1.0 version for a while.
Waiting for Noble to see If I can update without problems.
Hi. Thank you for replying.
In fact, I have tested on my side. Uninstalling fpc-src uninstall goverlay. But I don't want this comportement... Because it's not an execution dependency, just a build one.
If you know the way to avoid this problem... (Not tested to declare empty depends, I don't know if it will do the trick...)
For your question, goverlay-bin is the binary provided by upstream. At this moment, it is still in qt5 version 1.0.
This one is qt6 and rebuilt from source. The distributions aren't totally compatible with it, making the use of qt6ct for exemple for the theme.
Originally, goverlay-bin was named goverlay, but was a bin. So I have updated the name of the package.
And goverlay is from source as it must be.
I will continue to maintain both, but -bin will be left on 1.0 version for a while.
Waiting for Noble to see If I can update without problems.
@oklopfer possible to merge ? or miss something ? I have updated qt6pas pacscript so we need to up this one after.
This needs to be updated to the 5.0.0 spec
use goverlay-bin until I do the changes here. Have to test with v5. i also need to patch /bin/goverlay and add qt6ct for theming because debian and ubuntu are behind of upstream
