Re: solving file conflicts
On 10/10/23 02:41, Erich Eckner wrote: Hi fellow-archers, Hi! I have two packages, A and B, which both provide the same file X. ... Without knowing more its a bit hard to say. For example are A and B actually the same application but different versions (git vs stable). If so, then just make the unofficial git version conflict with official one. If not as above, without knowing more it's difficult to say. One possibility is to simply change the unofficial one to install in /usr/local (all of it /usr/local/etc, /usr/local/bin, /usr/local/lib, /usr/local/var and so on. That way nothing will conflict. That said, no 2 packages, unofficial or official should ever provide the same file at the same path location other than the case above where only 1 of the 2 can be installed due to conflicts=(other). regards, gene
Re: solving file conflicts
On 23/10/10 05:28AM, Genes Lists wrote: > On 10/10/23 02:41, Erich Eckner wrote: > > > > I have two packages, A and B, which both provide the same file X. > ... > One possibility is to simply change the unofficial one to install in > /usr/local (all of it /usr/local/etc, /usr/local/bin, /usr/local/lib, > /usr/local/var and so on. That way nothing will conflict. > Packages should _never_ install to /usr/local as per the Arch Linux Packaging Guidelines[0]! In general conflicts=(...) or rename is the way to go, usually the problem is mostly present for binaries and then renaming them is the way to go, see [1][2] for an example. I am also happy to help if you post some more detailed information! best, gromit [0] https://wiki.archlinux.org/title/Arch_package_guidelines#Package_etiquette [1] https://gitlab.archlinux.org/archlinux/packaging/packages/minio-client/-/blob/main/PKGBUILD?ref_type=heads#L38 [2] https://gitlab.archlinux.org/archlinux/packaging/packages/minio-client/-/blob/main/minio-client.install?ref_type=heads#L2 signature.asc Description: PGP signature
Re: solving file conflicts
Hi, sry for leaving out the details in the first place. I'll put them in-line: On Tue, 10 Oct 2023, Christian Heusel wrote: On 23/10/10 05:28AM, Genes Lists wrote: On 10/10/23 02:41, Erich Eckner wrote: I have two packages, A and B, which both provide the same file X. ... One possibility is to simply change the unofficial one to install in /usr/local (all of it /usr/local/etc, /usr/local/bin, /usr/local/lib, /usr/local/var and so on. That way nothing will conflict. This is (one possibility for) the second option, that I mentioned, which I was afraid might break a lot of stuff on my machines :-/ Packages should _never_ install to /usr/local as per the Arch Linux Packaging Guidelines[0]! good to know, thanks! In general conflicts=(...) or rename is the way to go, usually the problem is mostly present for binaries and then renaming them is the way to go, see [1][2] for an example. I am also happy to help if you post some more detailed information! The official package is tar, which now includes a /usr/bin/backup binary (script), that conflicts with the backup script, which I wrote myself and packaged in https://arch.eckner.net/os/x86_64/hardlinked-backups-1.7-1-any.pkg.tar.zst resp. https://git.eckner.net/Erich/archlinuxewe/tree/hardlinked-backups/PKGBUILD They provide different functionality - or at least, providing and conflicting tar is no option for me :-D. I see, that the root cause (and the "clean fix") is to rename the backup script in my package. However, I was hoping for a "hack" to simply tell pacman to ignore /usr/bin/backup from tar. The problem with the "rename /usr/bin/backup to /usr/bin/hard-linked-backup" approach is, that this is hooked up in cron and systemd timers/services, so backups run automatically (and I'm afraid, I'm also calling it *somewhere* manually to back up). Also, I'm a bit unsure, how to avoid such situations in future / for other packages. But I feel, like there is no general solution to this issue. best, gromit [0] https://wiki.archlinux.org/title/Arch_package_guidelines#Package_etiquette [1] https://gitlab.archlinux.org/archlinux/packaging/packages/minio-client/-/blob/main/PKGBUILD?ref_type=heads#L38 [2] https://gitlab.archlinux.org/archlinux/packaging/packages/minio-client/-/blob/main/minio-client.install?ref_type=heads#L2 Thanks for your answers! Regards, Erich
Re: solving file conflicts
On 10/10/23 07:00, Erich Eckner wrote: Hi, ... This is (one possibility for) the second option, that I mentioned, which I was afraid might break a lot of stuff on my machines :-/ I meant put it in /usr/local/xxx/ not directly in /usr/local. Or in /opt/xxx/ I see, that the root cause (and the "clean fix") is to rename the backup script in my package. Yah that is the right way. What I do is name all my stuff to ensure the name is reasonably unique ( not UUID unique but good enough ). For example you could simply add a prefix (or suffix) - like backup-ee. best gene
Installation image (services)
Hello... To improve the user experience, I suggest making the following changes to the installation image of the system. 1. Disable 'systemd-timesyncd.service' (the system time may not be set correctly on different machines; booting the main system after booting Arch Linux installation media and mounting hard disk may result in an error 'superblock last mount time is in the future'). 2. Enable 'gpm.service' and 'nftables.service'. Please... -- With respect and best regards, Mailsh.
Re: Installation image (services)
On Tue, Oct 10, 2023 at 7:08 PM wrote: > > > Hello... > > To improve the user experience, > I suggest making the following changes to the installation image of the > system. > > 1. Disable 'systemd-timesyncd.service' >(the system time may not be set correctly on different machines; >booting the main system after booting Arch Linux installation media and > mounting hard disk >may result in an error 'superblock last mount time is in the future'). > 2. Enable 'gpm.service' and 'nftables.service'. Please... > > -- > With respect and best regards, > Mailsh. > Disabling systemd-timesyncd would make any time related problems worse.
ttf-font
Hi! When installing many packages, we are offered 8 font options, among which there is no ttf-ubuntu-font-family. This font is the best font for browsers in my opinion. Add the option to choose ttf-ubuntu-font-family too. Please... -- With respect and best regards, Mailsh.
Remove a package together with a user and a group
Greetings! Users and groups created when installing some packages (avahi, usbmuxd) are not deleted along with its removal. Is it related to https://archlinux.org/todo/pacman-hooks-systemd-sysuserstmpfiles/ and requires some changes? Or should I always delete them manually? -- With respect and best regards, Mailsh.
Re: Remove a package together with a user and a group
Users and groups created when installing some packages (avahi, usbmuxd) are not deleted along with its removal. Is it related to https://archlinux.org/todo/pacman-hooks-systemd-sysuserstmpfiles/ and requires some changes? Or should I always delete them manually? Hello, If you decide, that you no longer need a user or a group, you have to manually delete it. This has to be a conscious decision, which is not something pacman or packages can do. I can’t locate authoritative information right now, but I believe the linked TODO entry from 2017 was related to replacing manual invocations of `systemd-tmpfiles` and `systemd-sysusers` with the corresponding drop-in configuration files. See commits cd35d646⁽¹⁾ and 072e646d⁽²⁾ as examples. ⁽¹⁾ https://gitlab.archlinux.org/archlinux/packaging/packages/apache/-/commit/cd35d646f87101351e1754e34661db971ac7de40 ⁽²⁾ https://gitlab.archlinux.org/archlinux/packaging/packages/mariadb/-/commit/072e646ddc5e84eb054921b10083879f759a280f
Re: ttf-font
El mar, 10-10-2023 a las 22:20 +0200, mail...@tuta.io escribió: > Hi! Hello! > When installing many packages, we are offered 8 font options, > among which there is no ttf-ubuntu-font-family. > This font is the best font for browsers in my opinion. > Add the option to choose ttf-ubuntu-font-family too. Please... The fact that a ttf-font is offered as an option to install when installing a package that needs it is because that package includes a "provides ttf-font" as for example ttf-liberation [1] does. For ttf-ubuntu-font-family to be offered as an option it should include that provides. My advice is to open a feature request bug [2] indicating this to be evaluated by the package maintainers. Greetings. [1]: https://archlinux.org/packages/extra/any/ttf-liberation/ [2]: https://bugs.archlinux.org/newtask?project=1&product_category=2&item_summary=%5Bttf-ubuntu-font-family%5D+PLEASE+ENTER+SUMMARY -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me signature.asc Description: This is a digitally signed message part
