| Summary: | sys-apps/pacman-5.1.0: version bump | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jonas Jelten <jj> |
| Component: | Current packages | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | gabemarcano, jj, jstein, proxy-maint, treecleaner |
| Priority: | Normal | Keywords: | PMASKED |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Deadline: | 2020-07-29 | ||
| Attachments: |
DRAFT: pacman-5.1.0
DRAFT: pacman-contrib-1.0.0 |
||
|
Description
Jonas Jelten
2018-06-28 11:45:06 UTC
Created attachment 538090 [details] DRAFT: pacman-5.1.0 Hi, I don't use pacman myself anymore (on Gentoo) and I don't find the time to maintain it so I'm going to drop it back into the "maintainer needed" grave. Another person that might be interested becoming a (proxied) maintainer is YmrDtnJu (IRC, freenode, channel #gentoo-de) and you might coordinate tasks with him. What needs to be done: - split into pacman and pacman-contrib - add USE="libressl" (bug 659754) - fix remaining bugs I will attach my draft ebuilds here and do the drop when the mirror at github.com is accessible again. If you are faster than me just drop me from the metadata.xml ;-) Created attachment 538092 [details]
DRAFT: pacman-contrib-1.0.0
I don't have time to post a patch, but something to take into account when making a pacman-contrib ebuild, is that it should probably still have the root point to the same one the pacman one is using. Even then, it looks like the Arch folk missed using those variables in places, e.g. pacman-key, which uses / hardcoded. I'm currently working through a mini-hell due to pacman chroot-ing to Gentoo's Arch chroot, and then being unable to find any binaries there (execv failed or something like that). Should we have the ebuilds install a copy of all binaries also to the Arch chroot? I don't think just straight copying would work, partially because the compiled pacman binaries would have the chroot path hardcoded, and once we're inside the chroot that path is wrong... the hacky solution would be to copy /bin/sh script wrappers around binaries supporting the --root argument to fix it in the chroot... but again, that's a bit on the hacky side. The root of the problem I'm encountering is that pacman-key actually chroots all the way into /var/chroot/archlinux, and by default there's nothing there. For now, I've run arch-boostrap.sh to that directory, which seems to be working fine for me, but that's also hacky in my opinion (plus it's 800 MB of storage just gone). > Even then, it looks like the Arch folk missed using those variables in places, e.g. pacman-key, which uses / hardcoded. I don't see anywhere it uses a hardcoded /, what I see it using is @sysconfdir@. Note that the Gentoo ebuild only configures --with-root-dir specially, meaning that configuration for pacman is expected to reside in /etc while managing a chroot in /var/chroot/archlinux. Is there any reason you think pacman-key should care about this? Note also that 5.1.0 adds a new "--sysroot" option, see https://git.archlinux.org/pacman.git/commit/?id=fae33a1faf3f94ea46049664ef483b2a3e0d3f01 In general, I think the intended use as far as operating inside the chroot is concerned, would be for there to be an actual archlinux system inside with a pacman program that isn't configured for a host/guest separation. It's been a year since I last looked at this, but from what I remember very vaguely the problem I ran into is that, at least out of the box with the "default" install using this ebuild, pacman-key when it can't find some files in the /etc folder of the chroot. I believe pacman-key was just an example, other pacman commands, I think, were failing due to things missing in the chroot. I no longer have this setup anymore so I don't have any way to test again, sorry. From what I remember what had me experimenting with pacman was that the Nintendo 3DS homebrew GCC compiler was being packaged for Arch and I wanted a way to install it "properly" so that I could uninstall it easily. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1229b2908e47bb2fed9cf77013f0440a421e1708 commit 1229b2908e47bb2fed9cf77013f0440a421e1708 Author: Mikle Kolyada <zlogene@gentoo.org> AuthorDate: 2020-07-29 11:29:19 +0000 Commit: Mikle Kolyada <zlogene@gentoo.org> CommitDate: 2020-07-29 11:31:31 +0000 sys-apps/pacman: remove last-rited pkg Closes: https://bugs.gentoo.org/659474 Closes: https://bugs.gentoo.org/627342 Closes: https://bugs.gentoo.org/627348 Closes: https://bugs.gentoo.org/711134 Signed-off-by: Mikle Kolyada <zlogene@gentoo.org> sys-apps/pacman/Manifest | 1 - .../pacman/files/pacman-5.0.2-CVE-2016-5434.patch | 136 --------------------- sys-apps/pacman/metadata.xml | 17 --- sys-apps/pacman/pacman-5.0.2-r2.ebuild | 117 ------------------ 4 files changed, 271 deletions(-) |
