New package: pacman-5.2.2 #22253
New package: pacman-5.2.2 #22253
Conversation
oreo639
force-pushed
the
pacman
branch
2 times, most recently
from
807a83d
to
db175d2
Compare
srcpkgs/pacman/template
Outdated
| make_dirs="/var/lib/pacman 0755 root root | ||
| /usr/var/cache/pacman/pkg 0755 root root | ||
| /usr/share/libalpm/hooks 0755 root root | ||
| /usr/share/pacman/keyrings 0755 root root" |
There was a problem hiding this comment.
Do we really want this? users shouldn't use pacman on a void linux root right? Are those directories required for chroot installations using pacman?
There was a problem hiding this comment.
Err, my bad, that last line isn't needed.
There was a problem hiding this comment.
You might want the keyrings directory in order to package the archlinux-keyring. Then pacman-key --populate $keyring_name will merge the keyring into /etc/pacman.d/gnupg and lsign the master keys.
If you're going to bootstrap archlinux from void, then pacman --root /path/to/chroot -Sy base_sytsem_packages is going to check those keys...
There was a problem hiding this comment.
@eli-schwartz I guess my acceptance for this PR was wrong?
I'm pretty much prefer to have you as maintainer for pacman.
Since you're obviously known pacman better than other people.
There was a problem hiding this comment.
To be honest, the keyrings/ directory isn't a direct requirement of pacman-key and it can be created just fine by e.g. an archlinux-keyring package or anything else which packages actual data there.
oreo639
force-pushed
the
pacman
branch
5 times, most recently
from
64dac7a
to
b19033e
Compare
| @@ -0,0 +1,13 @@ | |||
| # Template file for 'arch-install-scripts' | |||
There was a problem hiding this comment.
I'm fine with accepting pacman, but I don't like accepting those install scripts.
I don't have strong opinion, anyway.
There was a problem hiding this comment.
I just added it since I thought that that would be considered a better use case, if you and the other maintainers would rather it removed, I don't mind.
There was a problem hiding this comment.
FWIW: The arch-install-scripts are basically like debootstrap. Their only use is for installing chroots, in contrast to pacman which could be misused to scribble on xbps-tracked /usr.
There was a problem hiding this comment.
@eli-schwartz: I guess my acceptance to this PR is not that broken?
Please correct me if I were wrong. I'm not accepting arch-install-scripts is correct action, I guess?
There was a problem hiding this comment.
The pacman package is useful either way. For example, you can manage existing archlinux chroots with /usr/bin/pacman --sysroot /path/to/chroot.
However, I would argue that accepting arch-install-scripts is the correct action, and would encourage adding it in a followup PR. This would make it possible to create new archlinux chroots with /usr/bin/pacstrap /path/to/chroot.
There was a problem hiding this comment.
I'm sorry in advance if this sounds arguative.
I think arch-install-scripts could be downloaded to some unnamed directories.
From there, we can bootstrap a new ArchLinux chroot.
I've never used arch-install-scripts but I've used debootstrap (for some definition of use) and I think it's not necessary to be installed system-wide.
Based on that, I think I wasn't wrong to discourage arch-install-scripts
There was a problem hiding this comment.
That's true, pacstrap is a shellscript which is fairly trivial to download and build with m4 and make. You can run it directly from the git checkout. Minimal fuss.
There is still convenience value in having it installable, but that needs to be balanced against "yet-another-package" and "who's-going-to-review/maintain-this". I can hear both sides. :)
|
660/818 tests failed. |
Wdym? |
|
On 2020-06-10 18:04:36-0700, Oreo639 ***@***.***> wrote:
> 660/818 tests failed.
Wdym?
./xbps-src check pacman
…--
Danh
|
|
Thanks for letting me know, I fixed it. |
oreo639
force-pushed
the
pacman
branch
3 times, most recently
from
0d23bfa
to
2105bf8
Compare
|
On 2020-06-10 21:09:20-0700, Oreo639 ***@***.***> wrote:
Thanks for letting me know, I fixed it.
Look like fake-chroot should be in checkdepends instead of hostdepends
and depends?
Does pacman really depend on fakeroot?
…--
Danh
|
|
AFAIK fakeroot is needed for https://www.archlinux.org/packages/core/x86_64/fakeroot/ doesn't have pacman as a dependant. |
|
I wasn't aware of a checkdepends. I'll fix that. |
oreo639
force-pushed
the
pacman
branch
2 times, most recently
from
0e56ddf
to
4a83a3b
Compare
|
On 2020-06-13 08:41:16-0700, Érico Nogueira Rolim ***@***.***> wrote:
AFAIK fakeroot is needed for `makepkg`, not for pacman.
https://www.archlinux.org/packages/core/x86_64/fakeroot/ doesn't have pacman as a dependant.
Do you think it's better to split makepkg to a subpackage?
…--
Danh
|
I think it makes more sense to completely delete it, since it should be useless in Void (I believe it checks pacman for installed dependencies). If we want to keep it, though, I don't think making a separate package for such a niche use case is worth it. No idea what should be done with the |
|
On 2020-06-13 19:35:08-0700, Érico Nogueira Rolim ***@***.***> wrote:
> Do you think it's better to split makepkg to a subpackage?
I think it makes more sense to completely delete it, since it should
be useless in Void (I believe it checks pacman for installed
dependencies). If we want to keep it, though, I don't think making
a separate package for such a niche use case is worth it. No idea
what should be done with the `fakeroot` dependency in this case,
though.
Let's just delete it and keep only pacman.
…--
Danh
|
No, it doesn't. It simply runs the script and if the command doesn't exist it will error saying that the fakeroot command could not be found.
In my use case it is necessary (since sometimes I need to be able to build "portlibs" in order to pr them to the repo).
fakeroot is used when generating the package. |
|
@oreo639 Are you sure about I was unaware of the use case for devkitPro, though (nice to find someone who uses it c: ). In this case, how does it work? Do you install their packages in In this case, |
Almost all packages provided by devkitPro installs to It checks the packages installed with pacman for makedepends, but devkitpro doesn't use system applications in makedepends since the PKGBUILDS are supposed to be cross-platform. |
|
That makes sense. Cool! This use case is limited to glibc though, right? Unless one tries to build the whole thing from scratch. |
|
The libs they provide can be used from any system (since they only need to be compiled for the target system), but yeah the toolchain itself is only built for glibc. The repos are split into a dkp-libs and dkp-linux repos. |
|
If you're interested and building them isn't too hard, having packages for the compilers in Void would be pretty cool. That's not relevant to this PR, though :p sorry for side tracking. |
This isn't something we want to do. We went with pacman in order to manage the various tools and libraries we provide across a wide variety of linux systems without getting into replicating binaries across a whole bunch of package managers and the consequential quality control issues. We now have some 23 tool packages and a further 144 library packages with a fair degree of interdependence. Increasing complexity by involving multiple package managers (other than for pacman itself where necessary) will just spread what resources we have even thinner and risks fragmentation. It's a fairly delicate balancing act. |
|
@WinterMute I see. If it were to happen, I think it should be an effort completely from the Void side, not something devkitPro would have to fix. I can see how it might lead to new issues reported to you because of some build option or whatever, so it might be best for us to just package Pacman. I suppose the tools don't work on musl, right (at least out of the box)? That's the main reason I thought about packaging some of them in Void. But it definitely isn't your obligation to support another libc, so this shouldn't be relevant for you. |
|
@ericonr Of course it's relevant for us. Having other people package our tools always ends up messy because they end up being built in different environments and in different ways as well as often not being kept up to date with upstream. We have far too much experience of it going badly wrong when other people attempt to provide their own versions of our binaries which is why we require that any such tools have our branding removed from them and refrain from using the devkitPro naming. We would, as we always do, end up having to clear up the mess from people using tools they think we made that turn out not to work correctly when combined with the rest of the tools and libraries we distribute. Please do not attempt to build and maintain devkitPro binaries independently of our team. |
|
@ericonr Which sounds kind of harsh but you have no idea how much trouble has been caused by people repackaging our stuff over the years. |
|
@WinterMute I might have expressed myself badly. I meant that supporting other libcs isn't your obligation, and therefore my whole idea around shipping the toolchain isn't relevant for you, or anyone else. I can see how the phrase might have sounded, though. And thinking about it, since you probably do dependency management with pacman, having the toolchain installed locally wouldn't even solvea lot of the issues. Just to be clear, I can imagine the sort of issues you folks face, so again, regarding devkitPro, I think Void should only ship Pacman. |
|
@ericonr Thanks for understanding. Sorry I seemed harsh. I see what you meant now, which isn't what I read but it's all good. |
No description provided.