Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
El jue., 10 oct. 2019 a las 4:27, Ram Kumar via arch-general () escribió: > > Hi, i am not clear why the base group is being replaced.. i searched in > wiki and couldnt get a clear idea why. Could anyone plz explain? Yes. There is a plan to replace all package groups with metapackages? -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
> A good explanation in installation page could solve that. Yeah this is what we need..
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
Hi, there I like to say that the idea of having a base and base-extra meta package instead of previously base group is a great idea. For me Arch greatest strength is giving the user control and choice over their system and which software they need to install. Having a meta package for really essential packages which every Arch installation needs instead of previously general base group and having to choose which other package to install which some of them have alternatives like linux and linux-lts and so on, is exactly what that means to have choice and control over our system. I think many of complaints that arises with respect to this change is simply about not having enough information about these new changes and how from now on we must install a new Arch. That's where Arch other greatest strength come to play, our beloved wiki. A good explanation in installation page could solve that.
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
Hi, i am not clear why the base group is being replaced.. i searched in wiki and couldnt get a clear idea why. Could anyone plz explain?
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
Sounds good to me - do you have a suggested list of packages for base-extras or at least the list of what was pulled from the old base. Here's a diff of what was in the `base` group vs what is now in the `base` metapackage: $ comm -23 <(pacman -Sgq base | sort) <(expac -S "%D" base | tr -s " " "\n" | sort) cryptsetup device-mapper dhcpcd diffutils e2fsprogs inetutils jfsutils less linux linux-firmware logrotate lvm2 man-db man-pages mdadm nano netctl perl reiserfsprogs s-nail sysfsutils texinfo usbutils vi which xfsprogs
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
On Wed, 9 Oct 2019 12:13:28 -0400 Jude DaShiell wrote: > One dependency that exists is netctl and dialog. You can't use wifi-menu > unless dialog is pre-installed and wifi-menu if I'm not much mistaken is a > part of netctl. > > > > -- Optional dependencies are a standard part of Arch.
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
One dependency that exists is netctl and dialog. You can't use wifi-menu unless dialog is pre-installed and wifi-menu if I'm not much mistaken is a part of netctl. --
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
On 10/9/19 9:39 AM, Ralf Mardorf via arch-general wrote: > On Wed, 9 Oct 2019 10:19:38 -0400, Genes Lists via arch-general wrote: >> On 10/9/19 10:11 AM, Tinu Weber wrote: >>> https://web.archive.org/web/20190722121302/https://www.archlinux.org/groups/x86_64/base/ >>> >> Perfect - thank you! > IMO 'reiserfsprogs' is a good pointer for what reason to change 'base' > makes sense ;). It's a package good for backwards compatibility, but > probably not useful for a base install ;). > Heck, jfsutils. Does anyone actually use JFS outside of backwards compatibility support for older IBM systems? It bewilders me that it was in the original base group, honestly. Yaro
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
I, for one, think this isn’t going far enough. All packages should have explicit dependencies. I want to be able to run pacstrap ./dir nginx and get all the dependencies I need to run nginx inside a structure in dir. This would make arch very useful for chroot, namespaces and cgroups workflows (colloquially named “containerisation”). The old approach is silly. The complaints about the complexity of arch installs seem unusual in light of the fact that it’s already “difficult” and doesn’t really appear to have gotten any less difficult than it already was. The old base hasn’t been enough for a base system for me (and I assume most people) for years now while missing packages I would consider important and containing a bunch of unnecessary packages which I would happily do without except due to a lack of explicit dependencies I am not sure if my machine will still boot. If you’re worried about this change then there’s nothing stopping anyone from maintaining the far from perfect list of base group packages to install explicitly. — Tomasz Kramkowski >> On 9 Oct 2019, at 22:11, Tinu Weber wrote: >> >> On Wed, Oct 09, 2019 at 09:45:35 -0400, Genes Lists via arch-general wrote: >> My view - be helpful to have a list of packages no longer in base. >> >> A list of what changed is needed so users can add whatever they deem >> appropriate (presumably a kernel is one) to their own personal install >> package and ensure installations proceeed as usual. >> >> So, if somone can provide a complete list of no-longer included packages >> that would be super helpfui so we can all adjust as needed. > > https://web.archive.org/web/20190722121302/https://www.archlinux.org/groups/x86_64/base/
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
On Wed, 9 Oct 2019 10:19:38 -0400, Genes Lists via arch-general wrote: >On 10/9/19 10:11 AM, Tinu Weber wrote: >> >> https://web.archive.org/web/20190722121302/https://www.archlinux.org/groups/x86_64/base/ >> > >Perfect - thank you! IMO 'reiserfsprogs' is a good pointer for what reason to change 'base' makes sense ;). It's a package good for backwards compatibility, but probably not useful for a base install ;). -- “Awards are merely the badges of mediocrity.” ― Charles Ives
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
So, essentially if you want the full previous base group, you'd use # pacstrap /mnt base cryptsetup device-mapper dhcpcd diffutils e2fsprogs inetutils jfsutils less linux linux-firmware logrotate lvm2 man-db man-pages mdadm nano netctl perl reiserfsprogs s-nail texinfo usbutils vi which xfsprogs On Wed, Oct 9, 2019 at 10:19 AM Genes Lists via arch-general wrote: > > On 10/9/19 10:11 AM, Tinu Weber wrote: > > > > https://web.archive.org/web/20190722121302/https://www.archlinux.org/groups/x86_64/base/ > > > > Perfect - thank you!
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
On 10/9/19 10:11 AM, Tinu Weber wrote: > > https://web.archive.org/web/20190722121302/https://www.archlinux.org/groups/x86_64/base/ > Perfect - thank you!
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
On Wed, Oct 09, 2019 at 09:45:35 -0400, Genes Lists via arch-general wrote: > My view - be helpful to have a list of packages no longer in base. > > A list of what changed is needed so users can add whatever they deem > appropriate (presumably a kernel is one) to their own personal install > package and ensure installations proceeed as usual. > > So, if somone can provide a complete list of no-longer included packages > that would be super helpfui so we can all adjust as needed. https://web.archive.org/web/20190722121302/https://www.archlinux.org/groups/x86_64/base/
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
On 10/9/19 6:15 AM, mar77i via arch-general wrote: >...What problem are we solving, really? Problem: - there was a change - but the "diff" is not (obviously) visible, though I may have not looked in all the right places. The 'base' package has no history [1] - it came into existence 3 days ago. My view - be helpful to have a list of packages no longer in base. A list of what changed is needed so users can add whatever they deem appropriate (presumably a kernel is one) to their own personal install package and ensure installations proceeed as usual. So, if somone can provide a complete list of no-longer included packages that would be super helpfui so we can all adjust as needed. thanks. [1] https://git.archlinux.org/svntogit/packages.git/log/trunk?h=packages/base
[arch-general] trouble upgrading knewstuff
Hello, after upgrading my system yesterday plasma didn't work properly, the dektop didn't show wallpapers but remained black, dolphin and kontact didn't start, due to undefinded symbol in libKF5NewStuffCore.so.5.62.0. I temporarily solved the problem by downgrading the package to version 5.20.0. Maybe someone can fix the problem in version 5.62.0? Kind regards Will
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
Op wo 9 okt. 2019 12:15 schreef mar77i via arch-general < arch-general@archlinux.org>: > On Wednesday, October 9, 2019 12:03 PM, Mike Cloaked via arch-general < > arch-general@archlinux.org> wrote: > > > > Possibly intel-ucode would be very useful for many installs as well? > > > > Except for people who need amd-ucode... > > For a long time I was under the impression we relied on derivative distros > to dumb down things like system maintenance and installation for "regular" > users. The proposed "base-extra" group might be a marginally useful idea, > but the effort seems like a shot in the dark. What problem are we solving, > really? > AFAIK, the ease of "install this group" will be replaced with "please copy/paste this $reallylongline to get a usable base system when you're not deploying an (fully automated) container system. Arch is probably heading in a similar direction as Debian; a (relatively) low installed Base, with derivative distros using the same packages. Just my € 0,02 Mvg, Guus Snijders
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
The problem is that reducing the base group to the bare minimum made the installation of Arch much more complicated for the average or even moderately experienced user. I am not certain which packages I would even need to replicate the experience I am used to. A base-extra group would allow less experienced users to get a working installation done in a similar way as it has for the last ten years with the addition of one extra entry on the pacstrap command instead of having to sort through and determine which packages are needed after this change. I understand that Arch is developed to be simple for the developers and not the users, all I think many of us are asking for is a way to replicate the previous install mechanism with one small addition (a base-extra group that includes all the packages removed from base by this change). Thanks, Paul Stoetzer On Wed, Oct 9, 2019 at 06:15 mar77i via arch-general < arch-general@archlinux.org> wrote: > On Wednesday, October 9, 2019 12:03 PM, Mike Cloaked via arch-general < > arch-general@archlinux.org> wrote: > > > > Possibly intel-ucode would be very useful for many installs as well? > > > > Except for people who need amd-ucode... > > For a long time I was under the impression we relied on derivative distros > to dumb down things like system maintenance and installation for "regular" > users. The proposed "base-extra" group might be a marginally useful idea, > but the effort seems like a shot in the dark. What problem are we solving, > really? > > cheers! > mar77i > > > Sent with ProtonMail Secure Email. >
[arch-general] Broken dependency in extra - java-openjfx
Hi, to update my install I needed to remove java-openjfx. Probably an unneeded package, however, it's still provided by extra. Should I open a bug report or is fixing it already in the pipeline? There's an outdated package in testing since 2019-08-20, too. $ sudo pacman -Syu [snip] looking for conflicting packages... error: failed to prepare transaction (could not satisfy dependencies) :: installing jre-openjdk (13.u33-1) breaks dependency 'java-runtime-openjdk=12' required by java-openjfx $ pactree -r java-openjfx java-openjfx "Required By (0)" - https://www.archlinux.org/packages/?q=java-openjfx Regards, Ralf
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
On Wednesday, October 9, 2019 12:03 PM, Mike Cloaked via arch-general wrote: > > Possibly intel-ucode would be very useful for many installs as well? > Except for people who need amd-ucode... For a long time I was under the impression we relied on derivative distros to dumb down things like system maintenance and installation for "regular" users. The proposed "base-extra" group might be a marginally useful idea, but the effort seems like a shot in the dark. What problem are we solving, really? cheers! mar77i Sent with ProtonMail Secure Email.
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
On Tue, Oct 8, 2019 at 9:49 PM Genes Lists via arch-general < arch-general@archlinux.org> wrote: > On 10/8/19 4:34 PM, Eli Schwartz via arch-general wrote: > > > Really, I wish we would do as I'd wanted and transfer the "essential > > packages" which aren't actually essential and were thus not included in > > base.. to a new *group* called "base-extras", which would reflect its > > status as being mere recommendations, while providing a convenient way > > to choose to interactively install them, and allowing the Installation > > Guide to transition from: > > Sounds good to me - do you have a suggested list of packages for > base-extras or at least the list of what was pulled from the old base. > > Might be good for folks to add those to private install script / meta > package until such time as base-extras may be available. > > Thanks for mentioning linux-firmware - I just added kernels and a few > other items to my own, but I missed that one > Possibly intel-ucode would be very useful for many installs as well? -- mike c