Conflicts when using ly (display manager) and python-ly

pengeg · 2022-10-26 01:47:52

Hello,
I use Ly as my display manager and am wanting to install Frescobaldi which has python-ly, a lilypond frontend module, as a dependency. The issue arises as python-ly wants to occupy /usr/bin/ly. I think the issue is obvious when using Ly (the DM).
Pacman output because:

Packages (6) python-ly-0.9.7-3  python-poppler-qt5-21.3.0-1  python-pyqt5-webengine-5.15.6-1  python-qpageview-0.6.2-1
             qt5-webkit-5.212.0alpha4-17  frescobaldi-3.2-1

Total Download Size:   15.57 MiB
Total Installed Size:  62.80 MiB

:: Proceed with installation? [Y/n] 
:: Retrieving packages...
 python-pyqt5-webengine-5.15.6-1-x86_64                116.3 KiB   202 KiB/s 00:01 [-----------------------------------------------] 100%
 python-qpageview-0.6.2-1-any                          163.5 KiB   263 KiB/s 00:01 [-----------------------------------------------] 100%
 python-poppler-qt5-21.3.0-1-x86_64                    107.9 KiB   439 KiB/s 00:00 [-----------------------------------------------] 100%
 frescobaldi-3.2-1-any                                   2.4 MiB  2.32 MiB/s 00:01 [-----------------------------------------------] 100%
 python-ly-0.9.7-3-any                                 372.2 KiB   281 KiB/s 00:01 [-----------------------------------------------] 100%
 qt5-webkit-5.212.0alpha4-17-x86_64                     12.4 MiB  4.68 MiB/s 00:03 [-----------------------------------------------] 100%
 Total (6/6)                                            15.6 MiB  5.71 MiB/s 00:03 [-----------------------------------------------] 100%
(6/6) checking keys in keyring                                                     [-----------------------------------------------] 100%
(6/6) checking package integrity                                                   [-----------------------------------------------] 100%
(6/6) loading package files                                                        [-----------------------------------------------] 100%
(6/6) checking for file conflicts                                                  [-----------------------------------------------] 100%
error: failed to commit transaction (conflicting files)
python-ly: /usr/bin/ly exists in filesystem (owned by ly)
Errors occurred, no packages were upgraded.

Trilby · 2022-10-26 02:18:48

Yes ... and is there a question here? You should report this to the aur/ly maintainer to list python-ly as a conflict and / or suggest renaming the binary.

V1del · 2022-10-26 07:43:29

https://github.com/fairyglade/ly/issues/270

bulletmark · 2022-10-26 21:11:47

I wonder why the AUR back-end doesn't automatically detect and flag conflicts like this?

V1del · 2022-10-26 21:51:05

How should it? It doesn't build the packages.

bulletmark · 2022-10-26 21:54:40

V1del wrote:

How should it? It doesn't build the packages.

I'm asking why not?

PS: To be clear, it could just build the package for the purpose of detecting conflicts (and then toss the build away).

Last edited by bulletmark (2022-10-26 21:56:06)

loqs · 2022-10-26 22:02:51

bulletmark wrote:

V1del wrote:
How should it? It doesn't build the packages.
I'm asking why not?

Running a shell script that could potentially do anything is not safe. Also AUR hosts PKGBUILDs that use sources that have to be provided by the user. That is why .SRCINFO is generated by the package maintainer rather than by AUR.

2ManyDogs · 2022-10-26 22:19:55

Moving to AUR issues.

bulletmark · 2022-10-26 22:20:46

The build would be of course run in a sandbox and clearly all sources are publicly hosted, or have to be pushed to the AUR.

loqs · 2022-10-26 22:30:13

bulletmark wrote:

The build would be of course run in a sandbox and clearly all sources are publicly hosted, or have to be pushed to the AUR.

https://aur.archlinux.org/packages/ttf-ms-win10
https://aur.archlinux.org/packages/jre17
https://aur.archlinux.org/packages/unreal-engine
Edit:
You would also need to retain the built packages to supply dependencies for other AUR package. The resources needed to build all AUR packages would also not be insignificant.
The sandbox argument was not accepted when .SRCINFO was introduced what has changed?

Last edited by loqs (2022-10-26 22:51:02)

V1del · 2022-10-26 23:01:42

You are basically asking for/wondering about a service that is used to share text files between users to become a build bot building terabytes of data/software to verify file conflicts ahead of time for extreme edge cases that a few users will run into while said service is provided as a convenience for the former without any actual verification or support for even that purpose.

bulletmark · 2022-10-26 23:03:04

Ok, so there are some very obscure cases where it may not be possible for the backend to extract a list of target artifacts, but why not do it at least for 99.9% of PKGBUILDs where they can be determined and checked against a master list? Or, perhaps makepkg could be enhanced to add the target artifacts to the .SRCINFO? (although I realize there are various complications to that as well).

I remember a few years ago I named a binary to something in one of my AUR PKGBUILDs and after about another year a user posted that binary conflicted with some obscure tool in a misc utils official package. I renamed mine of course but I remember thinking how easy that mistake was to make and why the AUR does not help package maintainers detect it (e.g. at least against names in official packages). Does Arch automatically check for conflicts across official packages, or is it again simply up to maintainers to anticipate them?

Trilby · 2022-10-27 00:30:43

AUR package maintainers already build / test the package. It is their job to list conflicts in the conflicts array ... that's what it's there for.

"The AUR" should not build and check every package. It's quite easy for the packager to do the test themselves before posting the PKGBUILD.

To do so, get a list of files in your package, then check each against pacman -F:

find pkg/* -type f ! -name '.*' -printf '%P\n' \
	| while read fname; do pacman -F $fname; done

Alternatively, for large AUR packages, it might be more efficient to generate a repo file list and use `comm` to check them all in one go, e.g.:

find pkg/* -type f ! -name '.*' -printf '%P\n' | sort > pkgfiles
pacman -Flq | sort > repofiles
comm -12 pkgfiles repofiles

EDIT: after a couple quick tests it seems the second approach is more efficient regardless of the number of files in the AUR package so just use that.

Also, software authors of course should also do a general search when naming their tools, though that might not have been particularly relevant here. However, another upstream guideline that is relevant is that if you are thinking your tool should have a file under /usr/bin with just a two letter name, you should probably consider whether the importance of your tool justifies your apparent ego. An exceedingly vast majority of two-letter binaries originated from the early days of unix and have been around since then.

Last edited by Trilby (2022-10-27 00:59:31)

bulletmark · 2022-10-27 02:20:23

Well thanks Trilby. I have never realized that `pacman -F` has access to all packages. I thought it only searched locally installed packages.

Arch Linux

#1 2022-10-26 01:47:52

Conflicts when using ly (display manager) and python-ly

#2 2022-10-26 02:18:48

Re: Conflicts when using ly (display manager) and python-ly

#3 2022-10-26 07:43:29

Re: Conflicts when using ly (display manager) and python-ly

#4 2022-10-26 21:11:47

Re: Conflicts when using ly (display manager) and python-ly

#5 2022-10-26 21:51:05

Re: Conflicts when using ly (display manager) and python-ly

#6 2022-10-26 21:54:40

Re: Conflicts when using ly (display manager) and python-ly

#7 2022-10-26 22:02:51

Re: Conflicts when using ly (display manager) and python-ly

#8 2022-10-26 22:19:55

Re: Conflicts when using ly (display manager) and python-ly

#9 2022-10-26 22:20:46

Re: Conflicts when using ly (display manager) and python-ly

#10 2022-10-26 22:30:13

Re: Conflicts when using ly (display manager) and python-ly

#11 2022-10-26 23:01:42

Re: Conflicts when using ly (display manager) and python-ly

#12 2022-10-26 23:03:04

Re: Conflicts when using ly (display manager) and python-ly

#13 2022-10-27 00:30:43

Re: Conflicts when using ly (display manager) and python-ly

#14 2022-10-27 02:20:23

Re: Conflicts when using ly (display manager) and python-ly

Board footer