Re: [arch-announce] Switch to the base-devel meta package requires manual intervention
hi. after doing this `pacman -Syu base-devel` (and re-booting), a number of executables can't find some (out dated?) dynamic libraries. below are two lists: - one shows the affected binaries; - the other, just the list of un-found dynamic libraries. any thoughts? (sorry for e-mail formatting; my editor/e-mail program of choice is among the victims! :) (and, sorry for spurious sending to announce list; presumably that was squashed.) cheers, Greg bash archlinux (master): {49544} find /bin/ -type f -perm /a+x -print -exec ldd {} \; 2>&1 | awk 'NF == 1 { bin=$1; next } {print bin " ", $0}' | grep "not found" /bin/bggen libtiff.so.5 => not found /bin/bggen libjasper.so.6 => not found /bin/hb-view libchafa.so.0 => not found /bin/tiffdiff libtiff.so.5 => not found /bin/links libtiff.so.5 => not found /bin/xv libtiff.so.5 => not found /bin/xv libjasper.so.6 => not found /bin/dec265 libSDL-1.2.so.0 => not found /bin/emacs-28.1.91 libtiff.so.5 => not found /bin/r libopenblas.so.3 => not found /bin/tifficc libtiff.so.5 => not found /bin/makemhr libmysofa.so.1 => not found /bin/system76-firmware-cli libssl.so.1.1 => not found /bin/system76-firmware-cli libcrypto.so.1.1 => not found /bin/sensord librrd.so.8 => not found /bin/xcmap libtiff.so.5 => not found /bin/xcmap libjasper.so.6 => not found /bin/mpeg2dec libSDL-1.2.so.0 => not found bash archlinux (master): {49545} find /bin/ -type f -perm /a+x -print -exec ldd {} \; 2>&1 | awk 'NF == 1 { bin=$1; next } {print bin " ", $0}' | grep "not found" | awk '{print $2}' | sort -ulibSDL-1.2.so.0 libchafa.so.0 libcrypto.so.1.1 libjasper.so.6 libmysofa.so.1 libopenblas.so.3 librrd.so.8 libssl.so.1.1 libtiff.so.5
I checked the binaries on my laptop, and which packages owned the packages, of those, several, including tiffdiff, belonged to AUR packages and so not the responsibility of Arch maintainers. The only Arch-maintained packages I found affected were lm_sensors, fcitx5-configtool, and harfbuzz On 2/13/23 00:45, Greg Minshall wrote:
hi. after doing this `pacman -Syu base-devel` (and re-booting), a number of executables can't find some (out dated?) dynamic libraries.
below are two lists: - one shows the affected binaries; - the other, just the list of un-found dynamic libraries.
any thoughts? (sorry for e-mail formatting; my editor/e-mail program of choice is among the victims! :) (and, sorry for spurious sending to announce list; presumably that was squashed.)
cheers, Greg
bash archlinux (master): {49544} find /bin/ -type f -perm /a+x -print -exec ldd {} \; 2>&1 | awk 'NF == 1 { bin=$1; next } {print bin " ", $0}' | grep "not found" /bin/bggen libtiff.so.5 => not found /bin/bggen libjasper.so.6 => not found /bin/hb-view libchafa.so.0 => not found /bin/tiffdiff libtiff.so.5 => not found /bin/links libtiff.so.5 => not found /bin/xv libtiff.so.5 => not found /bin/xv libjasper.so.6 => not found /bin/dec265 libSDL-1.2.so.0 => not found /bin/emacs-28.1.91 libtiff.so.5 => not found /bin/r libopenblas.so.3 => not found /bin/tifficc libtiff.so.5 => not found /bin/makemhr libmysofa.so.1 => not found /bin/system76-firmware-cli libssl.so.1.1 => not found /bin/system76-firmware-cli libcrypto.so.1.1 => not found /bin/sensord librrd.so.8 => not found /bin/xcmap libtiff.so.5 => not found /bin/xcmap libjasper.so.6 => not found /bin/mpeg2dec libSDL-1.2.so.0 => not found bash archlinux (master): {49545} find /bin/ -type f -perm /a+x -print -exec ldd {} \; 2>&1 | awk 'NF == 1 { bin=$1; next } {print bin " ", $0}' | grep "not found" | awk '{print $2}' | sort -ulibSDL-1.2.so.0 libchafa.so.0 libcrypto.so.1.1 libjasper.so.6 libmysofa.so.1 libopenblas.so.3 librrd.so.8 libssl.so.1.1 libtiff.so.5
Michael Tindal <nihilistzsche@gmail.com> on Mon, 2023/02/13 00:53:
The only Arch-maintained packages I found affected were lm_sensors, fcitx5-configtool, and harfbuzz
I guess you did not install rrdtool, which is an optional dependency for lm_sensors. Probably something similar does apply for the others. -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
Michael,
I checked the binaries on my laptop, and which packages owned the packages, of those, several, including tiffdiff, belonged to AUR packages and so not the responsibility of Arch maintainers.
thanks! apologies for the noise! cheers, Greg
On Mon, 13 Feb 2023 11:45:57 +0300 Greg Minshall <minshall@umich.edu> wrote:
hi. after doing this `pacman -Syu base-devel` (and re-booting), a number of executables can't find some (out dated?) dynamic libraries.
below are two lists: - one shows the affected binaries; - the other, just the list of un-found dynamic libraries.
any thoughts? (sorry for e-mail formatting; my editor/e-mail program of choice is among the victims! :) (and, sorry for spurious sending to announce list; presumably that was squashed.)
cheers, Greg
bash archlinux (master): {49544} find /bin/ -type f -perm /a+x -print -exec ldd {} \; 2>&1 | awk 'NF == 1 { bin=$1; next } {print bin " ", $0}' | grep "not found" /bin/bggen libtiff.so.5 => not found /bin/bggen libjasper.so.6 => not found /bin/hb-view libchafa.so.0 => not found /bin/tiffdiff libtiff.so.5 => not found /bin/links libtiff.so.5 => not found /bin/xv libtiff.so.5 => not found /bin/xv libjasper.so.6 => not found /bin/dec265 libSDL-1.2.so.0 => not found /bin/emacs-28.1.91 libtiff.so.5 => not found /bin/r libopenblas.so.3 => not found /bin/tifficc libtiff.so.5 => not found /bin/makemhr libmysofa.so.1 => not found /bin/system76-firmware-cli libssl.so.1.1 => not found /bin/system76-firmware-cli libcrypto.so.1.1 => not found /bin/sensord librrd.so.8 => not found /bin/xcmap libtiff.so.5 => not found /bin/xcmap libjasper.so.6 => not found /bin/mpeg2dec libSDL-1.2.so.0 => not found bash archlinux (master): {49545} find /bin/ -type f -perm /a+x -print -exec ldd {} \; 2>&1 | awk 'NF == 1 { bin=$1; next } {print bin " ", $0}' | grep "not found" | awk '{print $2}' | sort -ulibSDL-1.2.so.0 libchafa.so.0 libcrypto.so.1.1 libjasper.so.6 libmysofa.so.1 libopenblas.so.3 librrd.so.8 libssl.so.1.1 libtiff.so.5
This is a partial update issue, one way or another. Instead of using ldd, which is recursive, check some of those binaries with lddtree from the pax-utils package. It'll reveal where the actual problems are. If you want to check in a script, you need to be using something like objdump or readelf that will show you just what the binary is linked to, not everything in the entire tree.
Doug,
This is a partial update issue, one way or another. Instead of using ldd, which is recursive, check some of those binaries with lddtree from the pax-utils package. It'll reveal where the actual problems are. If you want to check in a script, you need to be using something like objdump or readelf that will show you just what the binary is linked to, not everything in the entire tree.
thanks. i'll try to remember `lddtree`. cheers, Greg
Hello, I think quite a few people are not going to be surprised about this, but this is a major issue now. Having base-devel converted to a meta package is horrible, I can no longer get rid of sudo as it causes package conflicts and pacman will not allow the removal of it. I do not want sudo on my system, yay has stopped working with doas now, because it prioritises sudo and only resorts to doas (and then su if doas does not exist) if sudo does not exist, but because sudo will exist for everyone who wants to build AUR packages, yay is completely broken for me. It does not matter if doas is set within makepkg.conf, yay will always now use sudo, and there is nothing I can do other than try to get the developers to add a configuration file or some flag to convert it to doas. I have read the man pages, and unless I missed something, it does not seem like there is any way to stop using sudo. I do not want to use sudo, it is bloated for every day use and is only useful when it comes to developing packages, using the devtools, not when it comes to building packages where doas is more than enough to do so. Besides I use doas for developing packages anyways because I just dislike sudo. This change is frustrating!! I know this complaint is not going to change anything, but for those who also have this issue I will submit an issue to yay now and hope they implement a solution fast. Have a good night, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
Hello, I forgot to mention, if you really don't want sudo, just do: doas rm /usr/bin/sudo you must use sudo to do this, to add insult to injury :P But yeah thats my solution for now :) -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
Le 15/02/2023 à 02:59, Polarian a écrit :
Hello, Hi Polarian,
I think quite a few people are not going to be surprised about this, but this is a major issue now.
Having base-devel converted to a meta package is horrible, I can no longer get rid of sudo as it causes package conflicts and pacman will not allow the removal of it.
I do not want sudo on my system, yay has stopped working with doas now, because it prioritises sudo and only resorts to doas (and then su if doas does not exist) if sudo does not exist, but because sudo will exist for everyone who wants to build AUR packages, yay is completely broken for me.
[...]
I will submit an issue to yay now and hope they implement a solution fast.
Le 15/02/2023 à 03:08, Polarian a écrit : I forgot to mention, if you really don't want sudo, just do: doas rm /usr/bin/sudo
As stated in the associated Arch wiki page [1], AUR helpers are not supported by Arch Linux. According to this, I don't think the fact that `base-devel` switching to a meta package "breaks*" an AUR helper (only for `doas` users that do not want to use `sudo` at all in this case, additionally) will be taken as a legit reason to make the switch back, on its own. That also means that if there's any work to do regarding your current situation/concern (prioritize `doas` over `sudo` when using `yay`), it will indeed have to be done on `yay` side (as you already claimed by saying you'll submit an issue to `yay`, this is just a confirmation 😁). */As a side note, I don't think the fact that `yay` preferring using `sudo` over `doas` by default can/should be considered a "breakage". / For what it's worth, the decision to switch to a meta package has been taken regarding the fact that group packages won't pull new members automatically to users (in contrary of meta packages), which has been an issue regarding `base-devel` when the `debugedit` package has been recently added to the its members [2]. Now, if one *really* don't want `sudo` installed on their machine, they could just force its removal using `pacman` /(please, use this method instead of simply removing the `sudo` binary from your system)/: `pacman -Rdd sudo` _ __Important notes though:_ - According to the way meta packages work (which is actually the reason why we made the switch), `sudo` will be pulled back to your system at each `base-devel` updates (which I assume shouldn't happen /too /frequently though). - *This is obviously not recommended [3], do this at your own risks.* I hope this helps :) [1] https://wiki.archlinux.org/title/AUR_helpers [2] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/thread/NDOV3CDX2GRWOWOQA6ALGLGFQGP7XGK7/µ [3] https://wiki.archlinux.org/title/Pacman#Removing_packages -- Regards, Robin Candau
On Wed, 2023-02-15 at 08:31 +0100, Robin Candau wrote:
- According to the way meta packages work (which is actually the reason why we made the switch), `sudo` will be pulled back to your system at each `base-devel` updates (which I assume shouldn't happen too frequently though).
/etc/pacman.conf NoExtract = usr/bin/sudo
Le 15/02/2023 à 08:48, Ralf Mardorf a écrit :
On Wed, 2023-02-15 at 08:31 +0100, Robin Candau wrote:
- According to the way meta packages work (which is actually the reason why we made the switch), `sudo` will be pulled back to your system at each `base-devel` updates (which I assume shouldn't happen too frequently though). /etc/pacman.conf
NoExtract = usr/bin/sudo
While that would technically work, the sudo package is composed of /way/ more than just this binary file (`pacman -Ql sudo`). This is basically the same thing as what Polarian did initially (`doas rm /usr/bin/sudo`), which is only a partial removal of the `sudo` package; hence why I would not recommended it personally (specifically for people that "do not want sudo on their system"). You could eventually list all of the files installed by sudo via the `pacman -Ql sudo` output and put them in a "NoExtract" statement in the pacman.conf file but note that this list can change over time and that you'll still get the `sudo` package listed as installed (which can be an issue and a breakages source with certain packages depending how they're looking for sudo). Or... you can simply run `pacman -Rdd sudo` at each `base-devel` update to completely/properly remove it (which, once again, should be fairly rare) 😁. Note that, regarding the current `base-devel` situation, I do not recommend any of those two "solutions", which should both be used at your own risks. -- Regards, Robin Candau
On Wed, Feb 15, 2023 at 08:48:45 +0100, Ralf Mardorf wrote:
On Wed, 2023-02-15 at 08:31 +0100, Robin Candau wrote:
- According to the way meta packages work (which is actually the reason why we made the switch), `sudo` will be pulled back to your system at each `base-devel` updates (which I assume shouldn't happen too frequently though).
/etc/pacman.conf
NoExtract = usr/bin/sudo
Or run pacman with `--assume-installed=sudo` whenever you see it being pulled in. It will act as if the dependency was already installed. Geert
Am Mi, 15. Feb 2023 um 01:59:11 +00:00:00 schrieb Polarian <polarian@polarian.dev>:
Hello,
Hi.
I think quite a few people are not going to be surprised about this, but this is a major issue now.
Having base-devel converted to a meta package is horrible, I can no longer get rid of sudo as it causes package conflicts and pacman will not allow the removal of it.
You still can use it the "old way", by just installing the dependencies of the base-devel. Nothing stops you from doing this. # pacman -S $(LANG=C pacman -Si base-devel | grep "^Dep" | cut -d":" -f2 | sed 's/sudo//') Of course this way you will not see newly added dependencies, but thats the whole point why it was changed to a meta-package.
I do not want sudo on my system, yay has stopped working with doas now, because it prioritises sudo and only resorts to doas (and then su if doas does not exist) if sudo does not exist, but because sudo will exist for everyone who wants to build AUR packages, yay is completely broken for me.
It does not matter if doas is set within makepkg.conf, yay will always now use sudo, and there is nothing I can do other than try to get the developers to add a configuration file or some flag to convert it to doas.
For this you have to ask the people around your software to provide an option to set what you want to use. For example paru does provide something like this https://github.com/Morganamilo/paru/blob/master/paru.conf#L39 .
I have read the man pages, and unless I missed something, it does not seem like there is any way to stop using sudo. I do not want to use sudo, it is bloated for every day use and is only useful when it comes to developing packages, using the devtools, not when it comes to building packages where doas is more than enough to do so. Besides I use doas for developing packages anyways because I just dislike sudo.
This change is frustrating!!
It's always frustrating to follow your own way. You decide the path you travel on. ☕️
I know this complaint is not going to change anything, but for those who also have this issue I will submit an issue to yay now and hope they implement a solution fast.
Have a good night, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
And a good morning 😁️ Cheers.
El mié, 15-02-2023 a las 01:59 +0000, Polarian escribió:
I do not want sudo on my system
This is an issue that I have thought about a lot because I see that there are many people (including me) who prefer to have a simple executable (doas) to become root instead of a whole system that could send another man (or woman) to the moon and the truth is that there is no simple solution as the Arch Linux package system is set up. If our system had something like Debian (I'm not saying I like it, but it's a solution) with `update-alternatives`, you could choose `doas` as an alternative and uninstall `sudo`. Unfortunately, since we don't have it, there is no easy solution. A possible alternative would be to use `provides` in the packages, so that `doas` would provide `sudo` and then the user could choose what he wants. But this would cause `doas` and `sudo` to conflict with each other, since it would be necessary for `doas` to create a `/usr/bin/sudo -> doas` symbolic link so as not to break the compatibility of packages that require `sudo`. As I said, there is no simple solution. Greetings. -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
Am Mi, 15. Feb 2023 um 09:53:21 +01:00:00 schrieb Óscar García Amor <ogarcia@moire.org>:
El mié, 15-02-2023 a las 01:59 +0000, Polarian escribió:
I do not want sudo on my system
This is an issue that I have thought about a lot because I see that there are many people (including me) who prefer to have a simple executable (doas) to become root instead of a whole system that could send another man (or woman) to the moon and the truth is that there is no simple solution as the Arch Linux package system is set up.
If our system had something like Debian (I'm not saying I like it, but it's a solution) with `update-alternatives`, you could choose `doas` as an alternative and uninstall `sudo`. Unfortunately, since we don't have it, there is no easy solution.
A possible alternative would be to use `provides` in the packages, so that `doas` would provide `sudo` and then the user could choose what he wants. But this would cause `doas` and `sudo` to conflict with each other, since it would be necessary for `doas` to create a `/usr/bin/sudo -> doas` symbolic link so as not to break the compatibility of packages that require `sudo`.
This wouldn't work. doas is not a drop-in replacement for sudo. This link would also break lots of scrips and tools. The same goes for pkexec.
As I said, there is no simple solution.
Greetings. -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
El mié, 15-02-2023 a las 10:06 +0100, Fabian Bornschein escribió:
This wouldn't work. doas is not a drop-in replacement for sudo. This link would also break lots of scrips and tools. The same goes for pkexec.
El mié, 15-02-2023 a las 10:08 +0100, Jelle van der Waa escribió:
This is not an option as devtools which requires sudo is not compatible with doas (for usage outside of the build chroot). If it was then sudo could become optional potentially.
Yes, you are both right. I was just thinking of extremely simple cases in which nothing more than becoming root is expected, hence why I commented that it doesn't have a simple solution (apart from the fact that it makes no sense to mark doas and sudo as a conflict since both can coexist in the same system perfectly well). The only real solution would perhaps be to indicate that `sudo` and `doas` provide a third party, which we could call `become-root` (I'm not very good at giving original names), and in those packages that support `sudo` and `doas` interchangeably indicate that they depend on `become-root` and that you can choose. That said, if you have any package that depends (hard) on `sudo` you will have to install `sudo` no matter how much you don't like it. Greetings. -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
Le 15/02/2023 à 10:33, Óscar García Amor a écrit :
The only real solution would perhaps be to indicate that `sudo` and `doas` provide a third party, which we could call `become-root` (I'm not very good at giving original names), and in those packages that support `sudo` and `doas` interchangeably indicate that they depend on `become-root` and that you can choose.
Usually, packages that can be use with both `sudo` or `doas` list them as "optional dependencies" so you actually get to choose between one or another. This is what `yay` is doing for instance [1] (since we were talking about it), so that's already the case actually.
That said, if you have any package that depends (hard) on `sudo` you will have to install `sudo` no matter how much you don't like it. Indeed. Greetings. [1] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=yay#n14
-- Regards, Robin Candau
Hey On 15/02/2023 09:53, Óscar García Amor wrote:
El mié, 15-02-2023 a las 01:59 +0000, Polarian escribió:
I do not want sudo on my system
This is an issue that I have thought about a lot because I see that there are many people (including me) who prefer to have a simple executable (doas) to become root instead of a whole system that could send another man (or woman) to the moon and the truth is that there is no simple solution as the Arch Linux package system is set up.
If our system had something like Debian (I'm not saying I like it, but it's a solution) with `update-alternatives`, you could choose `doas` as an alternative and uninstall `sudo`. Unfortunately, since we don't have it, there is no easy solution.
This has been discussed in pacman-devel, I am not sure if this is coming soon or planned.
A possible alternative would be to use `provides` in the packages, so that `doas` would provide `sudo` and then the user could choose what he wants. But this would cause `doas` and `sudo` to conflict with each other, since it would be necessary for `doas` to create a `/usr/bin/sudo -> doas` symbolic link so as not to break the compatibility of packages that require `sudo`.
This is not an option as devtools which requires sudo is not compatible with doas (for usage outside of the build chroot). If it was then sudo could become optional potentially. https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/131
Having base-devel converted to a meta package is horrible, I can no longer get rid of sudo as it causes package conflicts and pacman will not allow the removal of it.
In that case your best bet is creating an empty package that just provides sudo and is empty otherwise. That will satisfy pacman and will also fulfill your desire to not have sudo on your system.
I do not want sudo on my system, yay has stopped working with doas now, because it prioritises sudo and only resorts to doas (and then su if doas does not exist) if sudo does not exist, but because sudo will exist for everyone who wants to build AUR packages, yay is completely broken for me.
But IMO your best bet is to use a package like doas-sudo-shim[0], which should allow most programs and scripts to continue working properly, even if they don't support doas directly. Best Sefa Eyeoglu https://scrumplex.net [0]: https://aur.archlinux.org/packages/doas-sudo-shim
I also think this is the best solution currently. It is much less messy than having to ignore the sudo binaries every update or remove them since this package provides sudo. On Wed, Feb 15, 2023 at 3:54 AM Sefa Eyeoglu <contact@scrumplex.net> wrote:
Having base-devel converted to a meta package is horrible, I can no longer get rid of sudo as it causes package conflicts and pacman will not allow the removal of it.
In that case your best bet is creating an empty package that just provides sudo and is empty otherwise. That will satisfy pacman and will also fulfill your desire to not have sudo on your system.
I do not want sudo on my system, yay has stopped working with doas now, because it prioritises sudo and only resorts to doas (and then su if doas does not exist) if sudo does not exist, but because sudo will exist for everyone who wants to build AUR packages, yay is completely broken for me.
But IMO your best bet is to use a package like doas-sudo-shim[0], which should allow most programs and scripts to continue working properly, even if they don't support doas directly.
Best
Sefa Eyeoglu https://scrumplex.net
-- Sincerely, Matthew Blankenbehler
On Wed, 2023-02-15 at 10:54 +0100, Sefa Eyeoglu wrote:
In that case your best bet is creating an empty package
Hi, that's indeed a very good workaround. I'm doing this for some potentially hard dependencies, that I don't want on my install, too. [rocketmouse@archlinux ~]$ pacman -Qi gvfs pulseaudio pulseaudio-bluetooth | grep Description Description : Dummy package Description : Dummy package Description : Dummy package Regards, Ralf
On 2/14/23 8:59 PM, Polarian wrote:
I do not want sudo on my system
IIRC, it is expected that Arch users have the base and base-devel packages (and all their dependencies) installed. So by not doing that, you're likely setting up your system in an unsupported configuration, and will wind up having to deal with some weird and difficult to diagnose problems down the road as a result. DR
On Wed, 15 Feb 2023 10:02:48 -0500 David Rosenstrauch <darose@darose.net> wrote:
On 2/14/23 8:59 PM, Polarian wrote:
I do not want sudo on my system
IIRC, it is expected that Arch users have the base and base-devel packages (and all their dependencies) installed. So by not doing that, you're likely setting up your system in an unsupported configuration, and will wind up having to deal with some weird and difficult to diagnose problems down the road as a result.
DR
No, there is no expectation to have base-devel installed. It's expected for building packages, that's it.
On 2/15/23 10:06 AM, Doug Newgard wrote:
On Wed, 15 Feb 2023 10:02:48 -0500 David Rosenstrauch <darose@darose.net> wrote:
On 2/14/23 8:59 PM, Polarian wrote:
I do not want sudo on my system
IIRC, it is expected that Arch users have the base and base-devel packages (and all their dependencies) installed. So by not doing that, you're likely setting up your system in an unsupported configuration, and will wind up having to deal with some weird and difficult to diagnose problems down the road as a result.
DR
No, there is no expectation to have base-devel installed. It's expected for building packages, that's it.
OK. But probably like 90+% of Arch users build packages, no? DR
On Wed, 15 Feb 2023 10:09:08 -0500 David Rosenstrauch <darose@darose.net> wrote:
On 2/15/23 10:06 AM, Doug Newgard wrote:
On Wed, 15 Feb 2023 10:02:48 -0500 David Rosenstrauch <darose@darose.net> wrote:
On 2/14/23 8:59 PM, Polarian wrote:
I do not want sudo on my system
IIRC, it is expected that Arch users have the base and base-devel packages (and all their dependencies) installed. So by not doing that, you're likely setting up your system in an unsupported configuration, and will wind up having to deal with some weird and difficult to diagnose problems down the road as a result.
DR
No, there is no expectation to have base-devel installed. It's expected for building packages, that's it.
OK. But probably like 90+% of Arch users build packages, no?
DR
On that specific system? Without using a chroot/container? All official packages are built in a clean chroot/container, which means there's no need for base-devel on the host system. Either way, not having base-devel is most definitely NOT an unsupported configuration.
On 2/15/23 10:23 AM, Doug Newgard wrote:
On Wed, 15 Feb 2023 10:09:08 -0500 David Rosenstrauch <darose@darose.net> wrote:
On 2/15/23 10:06 AM, Doug Newgard wrote:
On Wed, 15 Feb 2023 10:02:48 -0500 David Rosenstrauch <darose@darose.net> wrote:
On 2/14/23 8:59 PM, Polarian wrote:
I do not want sudo on my system
IIRC, it is expected that Arch users have the base and base-devel packages (and all their dependencies) installed. So by not doing that, you're likely setting up your system in an unsupported configuration, and will wind up having to deal with some weird and difficult to diagnose problems down the road as a result.
DR
No, there is no expectation to have base-devel installed. It's expected for building packages, that's it.
OK. But probably like 90+% of Arch users build packages, no?
DR
On that specific system? Without using a chroot/container? All official packages are built in a clean chroot/container, which means there's no need for base-devel on the host system. Either way, not having base-devel is most definitely NOT an unsupported configuration.
OK, I misspoke then, as regards your specific use case. Not sure if Polarian's use case was the same as yours though. DR
participants (14)
-
Christian Hesse
-
David Rosenstrauch
-
Doug Newgard
-
Fabian Bornschein
-
Geert Hendrickx
-
Greg Minshall
-
Jelle van der Waa
-
Matthew Blankenbeheler
-
Michael Tindal
-
Polarian
-
Ralf Mardorf
-
Robin Candau
-
Sefa Eyeoglu
-
Óscar García Amor