Should "base" packages be listed as dependencies?

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Should "base" packages be listed as dependencies?

Baptiste Jonglez
Hi,

I was pretty confident that "base" packages should be listed as
dependencies in PKGBUILDs, i.e. they are not assumed to be installed (as
opposed to "base-devel" for build dependencies).

This belief is reinforced by the fact that namcap gives dependencies error
about packages such as glibc (which is in "base"):

    E: Dependency glibc detected and not included (libraries ['usr/lib/libc.so.6', 'usr/lib/libcrypt.so.1'] needed in files ['usr/lib/libcli.so.1.9.7'])

But I could not find any documentation about this.  On the contrary, this
wiki page [1] says the opposite:

    In addition, the base group is assumed to be installed on *all* Arch
    systems.

Am I missing something obvious?

Thanks,
Baptiste

[1] https://wiki.archlinux.org/index.php/Makepkg#Usage

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Should "base" packages be listed as dependencies?

Lex Black
Base and base-devel are a requirement for using the AUR and those packages shouldn't be added to the depends.

See the prerequisites on the AUR wiki page.
Reply | Threaded
Open this post in threaded view
|

Re: Should "base" packages be listed as dependencies?

Bartłomiej Piotrowski-3
On 2017-03-22 21:51, Lex Black wrote:
> Base and base-devel are a requirement for using the AUR and those packages shouldn't be added to the depends.
>
> See the prerequisites on the AUR wiki page.
>

Well, no.

Someone who builds a package is expected to have base-devel installed.
It does not apply to the base group. And worth noting, base-devel does
not include base.

Bartłomiej
Reply | Threaded
Open this post in threaded view
|

Re: Should "base" packages be listed as dependencies?

Tinu Weber
In reply to this post by Lex Black
On Wed, Mar 22, 2017 at 21:51:50 +0100, Lex Black wrote:
> Base and base-devel are a requirement for using the AUR and those
> packages shouldn't be added to the depends.
>
> See the prerequisites on the AUR wiki page.

The policy is only about base-devel; for base, there does not appear to
be a clear policy.

I personally always put those packages in the dependency list, because I
consider the choice of packages in base to be extremely arbitrary. But
some TUs and devs apparently do not do that, which is probably why there
is this "troubleshooting" part in [2], where they recommend installing
*all* of base.

[1] https://wiki.archlinux.org/index.php/Arch_User_Repository#Foo_in_the_AUR_does_not_compile_when_I_run_makepkg.3B_what_should_I_do.3F

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Should "base" packages be listed as dependencies?

Doug Newgard-2
In reply to this post by Baptiste Jonglez
On Wed, 22 Mar 2017 21:45:13 +0100
Baptiste Jonglez <[hidden email]> wrote:
>
> Am I missing something obvious?
>
> Thanks,
> Baptiste

There's no specific rule about it. Some packagers will include packages in base
in the depends, some won't. It's completely up to them.

attachment0 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Should "base" packages be listed as dependencies?

Lex Black
In reply to this post by Bartłomiej Piotrowski-3
Am 22. März 2017 21:56:57 MEZ schrieb "Bartłomiej Piotrowski" <[hidden email]>:

>On 2017-03-22 21:51, Lex Black wrote:
>> Base and base-devel are a requirement for using the AUR and those
>packages shouldn't be added to the depends.
>>
>> See the prerequisites on the AUR wiki page.
>>
>
>Well, no.
>
>Someone who builds a package is expected to have base-devel installed.
>It does not apply to the base group. And worth noting, base-devel does
>not include base.
>
>Bartłomiej

Ah, kinda on the wrong way. Dunno why I was thinking base-devel would include base.
Thanks for the correction
Reply | Threaded
Open this post in threaded view
|

Re: Should "base" packages be listed as dependencies?

NicoHood-3
In reply to this post by Doug Newgard-2
On 03/22/2017 10:12 PM, Doug Newgard wrote:

> On Wed, 22 Mar 2017 21:45:13 +0100
> Baptiste Jonglez <[hidden email]> wrote:
>>
>> Am I missing something obvious?
>>
>> Thanks,
>> Baptiste
>
> There's no specific rule about it. Some packagers will include packages in base
> in the depends, some won't. It's completely up to them.
>
You need to include base packages which are not in base-devel, as the
package won't build without those sometimes. For example some packages
detect systemd at build time and then adds its service files to the
package. At least as makedepends they need to be specified.

I was also angry about this first, but this is actually a more clear way
to build packages without unnecessary dependencies. Every user should
build packages using devtools anyways to detect deps properly and to
produce clean packages.

~Nico


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Should "base" packages be listed as dependencies?

tur-users mailing list
On 03/22/2017 05:36 PM, NicoHood wrote:

> On 03/22/2017 10:12 PM, Doug Newgard wrote:
>> On Wed, 22 Mar 2017 21:45:13 +0100
>> Baptiste Jonglez <[hidden email]> wrote:
>>>
>>> Am I missing something obvious?
>>>
>>> Thanks,
>>> Baptiste
>>
>> There's no specific rule about it. Some packagers will include packages in base
>> in the depends, some won't. It's completely up to them.
>
> You need to include base packages which are not in base-devel, as the
> package won't build without those sometimes. For example some packages
> detect systemd at build time and then adds its service files to the
> package. At least as makedepends they need to be specified.
>
> I was also angry about this first, but this is actually a more clear way
> to build packages without unnecessary dependencies. Every user should
> build packages using devtools anyways to detect deps properly and to
> produce clean packages.
makedepends, maybe.

Arch Linux does not support people who don't have systemd installed
though, and regarding Baptiste's initial example of glibc, if you don't
have glibc installed then your system is so screwed up it's not even
funny...

Given that the official instructions for installing Arch boils down to
"install the base group into a blank partition and arrange a bootloader
to boot that base group", I feel it is eminently reasonable to assume
all valid Arch Linux systems have the base group installed... especially
because some repo packages *are* built with implicit dependencies
because of that exact logic. You really can't just go around
uninstalling parts of base, or rather you can, but then it is up to you
to know when your unsupported actions are likely to break something.
(I say this with the full knowledge that I myself uninstall certain
things I don't feel belong in base at all. I am willing to debug my own
self-inflicted problems...)

Though thinking about this, I actually wonder, maybe devtools should
instruct you (rhet.) to install both base and base-devel into a build
chroot...

...

@Baptiste,

The fact that namcap emits a warning, doesn't actually mean anything. :)
namcap says/doesn't say a lot of things that are wrong, and all that
*this* means is that namcap doesn't explicitly include code to filter
out warnings for base packages. That could be because a) the namcap
maintainer felt they should be dependencies anyway, or b) no one thought
of it/decided to implement a filter, or c) both.
namcap being what it is, I am 99.999999999999% sure it is either b or c.

--
Eli Schwartz


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Should "base" packages be listed as dependencies?

beest
On Wed, Mar 22, 2017 at 07:17:17PM -0400, Eli Schwartz via aur-general wrote:

> Arch Linux does not support people who don't have systemd installed
> though, and regarding Baptiste's initial example of glibc, if you don't
> have glibc installed then your system is so screwed up it's not even
> funny...
>
> Given that the official instructions for installing Arch boils down to
> "install the base group into a blank partition and arrange a bootloader
> to boot that base group", I feel it is eminently reasonable to assume
> all valid Arch Linux systems have the base group installed... especially
> because some repo packages *are* built with implicit dependencies
> because of that exact logic. You really can't just go around
> uninstalling parts of base, or rather you can, but then it is up to you
> to know when your unsupported actions are likely to break something.
> (I say this with the full knowledge that I myself uninstall certain
> things I don't feel belong in base at all. I am willing to debug my own
> self-inflicted problems...)
>
> Though thinking about this, I actually wonder, maybe devtools should
> instruct you (rhet.) to install both base and base-devel into a build
> chroot...

Also xorg-server is generally implicit for anything requiring X
(optionally or otherwise), but that's also not really codified anywhere.
The only guidance anyone is given is that only base-devel is assumed to
be installed for makedepends, but in practice that's hardly the sole
circumstance.

I'm also on the side of explicitly assuming that base is installed (and
having the wiki and PKGBUILD dox reflect as much), but before that there
should possibly be a discussion about what actually belongs in base in
the first place. A few folks are of the mind that a good chunk of the
group is wholly unnecessary and should be culled.
Reply | Threaded
Open this post in threaded view
|

Re: Should "base" packages be listed as dependencies?

Giancarlo Razzolini-2
In reply to this post by Doug Newgard-2
Em março 22, 2017 18:12 Doug Newgard escreveu:
>
> There's no specific rule about it. Some packagers will include packages in base
> in the depends, some won't. It's completely up to them.
>

But, if at least the maintainers built their packages using a clean chroot, they
would know what they are missing from base to include on depends. I don't think
we need to enforce that rule to the AUR, but it is a rule for repo packages for
a good reason. We could, however, suggest on the wiki, if it isn't already, that
even for the AUR, the *maintainers* build their packages using devtools.

Cheers,
Giancarlo Razzolini

attachment0 (887 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Should "base" packages be listed as dependencies?

tur-users mailing list
On Thu, 2017-03-23 at 01:38 +0000, Giancarlo Razzolini wrote:

> Em março 22, 2017 18:12 Doug Newgard escreveu:
> >
> > There's no specific rule about it. Some packagers will include
> > packages in base
> > in the depends, some won't. It's completely up to them.
> >
>
> But, if at least the maintainers built their packages using a clean
> chroot, they
> would know what they are missing from base to include on depends. I
> don't think
> we need to enforce that rule to the AUR, but it is a rule for repo
> packages for
> a good reason. We could, however, suggest on the wiki, if it isn't
> already, that
> even for the AUR, the *maintainers* build their packages using
> devtools.
>
> Cheers,
> Giancarlo Razzolini
Doesn't the standard chroot end up with all of base and base-devel or
is that not currently the case?

signature.asc (883 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Should "base" packages be listed as dependencies?

tur-users mailing list
In reply to this post by beest
On 03/22/2017 09:07 PM, beest wrote:
> I'm also on the side of explicitly assuming that base is installed (and
> having the wiki and PKGBUILD dox reflect as much), but before that there
> should possibly be a discussion about what actually belongs in base in
> the first place. A few folks are of the mind that a good chunk of the
> group is wholly unnecessary and should be culled.

I will absolutely agree that there are additional packages in base that
shouldn't be. I have brought this point up before a couple times....
Unfortunately, the maintainers of those packages seem to be entirely
happy to leave them as-is, maybe on the assumption borne out in this
thread that no one cares what is in base (except for silly things like
the Installation Guide which no one cares about either, of course).

Bizarrely, other package groups seem to have clearly-defined meanings
which is strongly against the precedent set by the current base group...

fsck/mkfs support for nonstandard filesystems
- xfsprogs
- reiserfsprogs
- jfsutils

Heavily discouraged by pretty much everyone, why on earth would it match
any conceivable definition of "base"...
- netctl :(

Needed for device encryption/LVM/RAID, which not everyone uses
- cryptsetup
- lvm2
- device-mapper
- mdadm

No firm reason for including
- s-nail (an inert mass unless you go out of your way to configure it)
- nano (vi is the standard, and *I* don't even want to include that
  because vim)


I would love for all these to be dropped from base, as I consider them
neither recommended (Scimmia's concept of base IIRC) nor critical (the
intuitive concept of base).

Well, maybe the LVM/encryption stuff could be said to be recommended.
But not critical.

--
Eli Schwartz


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Should "base" packages be listed as dependencies?

Doug Newgard-2
In reply to this post by tur-users mailing list
On Wed, 22 Mar 2017 22:02:31 -0400
Daniel Micay via aur-general <[hidden email]> wrote:

> On Thu, 2017-03-23 at 01:38 +0000, Giancarlo Razzolini wrote:
> > Em março 22, 2017 18:12 Doug Newgard escreveu:  
> > >
> > > There's no specific rule about it. Some packagers will include
> > > packages in base
> > > in the depends, some won't. It's completely up to them.
> > >  
> >
> > But, if at least the maintainers built their packages using a clean
> > chroot, they
> > would know what they are missing from base to include on depends. I
> > don't think
> > we need to enforce that rule to the AUR, but it is a rule for repo
> > packages for
> > a good reason. We could, however, suggest on the wiki, if it isn't
> > already, that
> > even for the AUR, the *maintainers* build their packages using
> > devtools.
> >
> > Cheers,
> > Giancarlo Razzolini  
>
> Doesn't the standard chroot end up with all of base and base-devel or
> is that not currently the case?

All of base-devel, but not all of base.
Reply | Threaded
Open this post in threaded view
|

Re: Should "base" packages be listed as dependencies?

xyne
In reply to this post by beest
On 2017-03-22 19:17 -0400
Eli Schwartz via aur-general wrote:

>Given that the official instructions for installing Arch boils down to
>"install the base group into a blank partition and arrange a bootloader
>to boot that base group", I feel it is eminently reasonable to assume
>all valid Arch Linux systems have the base group installed... especially
>because some repo packages *are* built with implicit dependencies
>because of that exact logic. You really can't just go around
>uninstalling parts of base, or rather you can, but then it is up to you
>to know when your unsupported actions are likely to break something.
>(I say this with the full knowledge that I myself uninstall certain
>things I don't feel belong in base at all. I am willing to debug my own
>self-inflicted problems...)
>
>Though thinking about this, I actually wonder, maybe devtools should
>instruct you (rhet.) to install both base and base-devel into a build
>chroot...



On 2017-03-22 21:07 -0400
beest wrote:

>I'm also on the side of explicitly assuming that base is installed (and
>having the wiki and PKGBUILD dox reflect as much), but before that there
>should possibly be a discussion about what actually belongs in base in
>the first place. A few folks are of the mind that a good chunk of the
>group is wholly unnecessary and should be culled.


The PKGBUILD should specify all necessary information for full dependency
resolution without assuming anything other than base-devel*. Extending the
assumption to the full base group just so some packagers can avoid typing a
few extra words *once* when they create the PKGBUILD is just laziness. It's not
even a real burden given that most deps are pulled in indirectly by other
deps so at most you usually only need to list a few. If a PKGBUILD does not
contain all information for full dependency resolution (minus base-devel), then
it is technically incorrect (it lacks required metadata).

There is no "base installation" of Arch Linux. That's one of the defining
features of this distro. Forcing some people to install bloat and cruft (or
play dependency spelunker) to save a few keystrokes in a PKGBUILD is just
wrong. It also fails to consider use cases such as minimalist chroots for
building packages.


Regards,
Xyne

* I could even argue that makepkg should check for base-devel and include it in
  dependency resolution automatically with the --syncdeps option.
Reply | Threaded
Open this post in threaded view
|

Re: Should "base" packages be listed as dependencies?

tur-users mailing list
In reply to this post by tur-users mailing list
On 03/22/2017 10:02 PM, Daniel Micay via aur-general wrote:
> Doesn't the standard chroot end up with all of base and base-devel or
> is that not currently the case?

The "standard chroot" is a help message in makechrootpkg saying
```
The chroot "root" directory must be created via the following
command:
    mkarchroot <chrootdir>/root base-devel
```
and corresponding automation in archbuild.

mkarchroot is really just a btrfs/CHROOT_VERSION wrapper around pacstrap...

As I said earlier, perhaps this is something that could/should be rethought?

--
Eli Schwartz


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Should "base" packages be listed as dependencies?

tur-users mailing list
In reply to this post by xyne
On 03/22/2017 11:24 PM, Xyne wrote:
> The PKGBUILD should specify all necessary information for full dependency
> resolution without assuming anything other than base-devel*. Extending the
> assumption to the full base group just so some packagers can avoid typing a
> few extra words *once* when they create the PKGBUILD is just laziness. It's not
> even a real burden given that most deps are pulled in indirectly by other
> deps so at most you usually only need to list a few. If a PKGBUILD does not
> contain all information for full dependency resolution (minus base-devel), then
> it is technically incorrect (it lacks required metadata).

Well, it also means, for example, that you don't have to keep listing
things like bash and glibc in literally hundreds of PKGBUILDs.

> There is no "base installation" of Arch Linux. That's one of the defining
> features of this distro. Forcing some people to install bloat and cruft (or
> play dependency spelunker) to save a few keystrokes in a PKGBUILD is just
> wrong.

There absolutely is a base installation. Unless you are suggesting e.g.
systemd-less systems constitute a supported Arch Linux installation?

> It also fails to consider use cases such as minimalist chroots for
> building packages.

I thought that was the point of suggesting that minimalist build chroots
potentially require base as well...

But hey, I am also perfectly happy listing them only as makedepends. :)

--
Eli Schwartz


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Should "base" packages be listed as dependencies?

xyne
>Well, it also means, for example, that you don't have to keep listing
>things like bash and glibc in literally hundreds of PKGBUILDs.

I understand that argument, but it is framed as if people are writing hundreds
of PKGBUILDs at once and the added deps are overly tedious to include, when in
fact they are written one at a time and it's only a few extra words (at most)
alongside however many constitute the PKGBUILD. For makedeps, most of these are
not even needed because they are indirect deps of base-devel. All runtime deps
should be resolved though, either directly or indirectly.

The only valid technical argument would be if the overhead of the dependency
checks is prohibitive. I expect that it is negligible (but admittedly haven't
checked) and it is worth technical correctness.

It's like quoting path variables in PKGBUILDs: most people build in "sane"
paths but it's still poor form to omit the quotes and assume that no one builds
on paths with spaces. The arguments "but I don't want to type more quotes" and
"but all those quotes across all the PKGBUILDs take so many bytes" are rightly
rejected.



>> There is no "base installation" of Arch Linux. That's one of the defining
>> features of this distro. Forcing some people to install bloat and cruft (or
>> play dependency spelunker) to save a few keystrokes in a PKGBUILD is just
>> wrong.  
>
>There absolutely is a base installation. Unless you are suggesting e.g.
>systemd-less systems constitute a supported Arch Linux installation?

This isn't about what is officially "supported". This is about how one tool
performs a task. Arch provides flexibility. There are custom kernels and
alternative init systems in the AUR for example. If you customize your system
then you are expected to deal with problems arising from that customization
yourself, but core functionality of the package manager should not rely on all
users installing essentially the same base system. We are talking about
dependency resolution here. Pacman is not tied to systemd or whatever else you
consider to be part of a "base installation". It shouldn't even matter what
other packages the user is using as long as pacman's own deps are satisfied.
For dependency resolution, Pacman's job is to determine what the user wants to
install and then figure out what else the user needs to install it. All it
needs to do that is the correct metadata, which is just a few extra words in
some text files. That is better than implicit assumptions that may silently
change in the future.




>I thought that was the point of suggesting that minimalist build chroots
>potentially require base as well...

A chroot that requires all of the base group is not minimal, it's bloated.


It's like a lazy fruit vendor dumping apples, oranges, bananas, etc. into one
giant bin because he can't be bothered to put them in separate bins (even
though he has them, and it would be simple to do), then forcing customers who
only want apples to buy big boxes of mixed fruit so that they can sort out the
apples themselves and throw the rest of the fruit away (after paying for it).


Regards,
Xyne
Reply | Threaded
Open this post in threaded view
|

Re: Should "base" packages be listed as dependencies?

Ralf Mardorf
In reply to this post by tur-users mailing list
On Wed, 22 Mar 2017 22:31:34 -0400, Eli Schwartz via aur-general wrote:
>nano (vi is the standard, and *I* don't even want to include that
>because vim)

For modern Linux distros nano has become a standard as well. What's bad
with providing it by base? Linux isn't UNIX from the 70s. I'm not using
reiser, but what is so problematic with including reiserfsprogs? It at
least was a Linux FS preferred as default FS for e.g. Suse a few
years back? It's idiotic to discuss such trivialities. Some prefer it
more old school others less old school. You are more old school but
that's not enough, you even want to discuss what belongs to the old
school.

Regards,
Ralf
Reply | Threaded
Open this post in threaded view
|

Re: Should "base" packages be listed as dependencies?

tur-users mailing list
In reply to this post by xyne
On 03/23/2017 02:29 AM, Xyne wrote:

>> Well, it also means, for example, that you don't have to keep listing
>> things like bash and glibc in literally hundreds of PKGBUILDs.
>
> I understand that argument, but it is framed as if people are writing hundreds
> of PKGBUILDs at once and the added deps are overly tedious to include, when in
> fact they are written one at a time and it's only a few extra words (at most)
> alongside however many constitute the PKGBUILD. For makedeps, most of these are
> not even needed because they are indirect deps of base-devel. All runtime deps
> should be resolved though, either directly or indirectly.
>
> The only valid technical argument would be if the overhead of the dependency
> checks is prohibitive. I expect that it is negligible (but admittedly haven't
> checked) and it is worth technical correctness.
>
> It's like quoting path variables in PKGBUILDs: most people build in "sane"
> paths but it's still poor form to omit the quotes and assume that no one builds
> on paths with spaces. The arguments "but I don't want to type more quotes" and
> "but all those quotes across all the PKGBUILDs take so many bytes" are rightly
> rejected.
It is not poor form, it is outright wrong.

BECAUSE PATHS WITH SPACES ARE A VALID USE-CASE! The only reason I don't
feel comfortable using such build paths purely to show it can be done...
is because AUR maintainers are by and large idiots who upload
irresponsible garbage that breaks all the time and has missing
dependencies of *all* sorts, among other numerous common problems when
sifting through huge mounds of absolutely anything authored by
absolutely anyone. :p

And a system that does not have glibc installed is not a valid use-case.
A system without bash is not a valid use-case. A system without systemd
is not a valid use-case, regardless of how many completely-unsupported
people kludge it together with AUR packages (which also are unsupported).

I don't have actual numbers for the dependency checking time... but it
is surely nonzero, and I see no reason to go out of my way to add them
purely for the sake of slowing down pacman's depchecks to whatever
degree, adding PKGBUILD code churn and decreasing clarity by cluttering
it with obvious no-brainers, given that the result is still lacking in
technical correctness, since *technically*, a binary that only links to
glibc still needs a lot of other stuff like a working system running a
linux kernel to run.

Redefining dependencies as shared library linkages would make this a
more compelling argument.

...

Really, if you want technical correctness, then I expect to be able to
pacstrap any single package into an empty partition/directory and have
pacman resolve dependencies to a sufficient degree to result in a
bootable/chrootable minimal installation in which that package functions
as expected.

>>> There is no "base installation" of Arch Linux. That's one of the defining
>>> features of this distro. Forcing some people to install bloat and cruft (or
>>> play dependency spelunker) to save a few keystrokes in a PKGBUILD is just
>>> wrong.  
>>
>> There absolutely is a base installation. Unless you are suggesting e.g.
>> systemd-less systems constitute a supported Arch Linux installation?
>
> This isn't about what is officially "supported". This is about how one tool
> performs a task. Arch provides flexibility. There are custom kernels and
> alternative init systems in the AUR for example. If you customize your system
> then you are expected to deal with problems arising from that customization
> yourself, but core functionality of the package manager should not rely on all
> users installing essentially the same base system.
No, just core functionality of, you know the system. Which explicitly
refuses to support the alternative init systems, with undertones of
such-AUR-packages-may-be-crazy. Arch happily compiles runtime
dependencies of systemd into everything, serenely unconcerned about the
trouble this causes the poor saps who try purging systemd.

Arch is *not* about choice or flexibility, not when it comes to the base
system itself. This is a rather emphatic aspect of the Arch Way. After
several complaints from users about systemd specifically, this *had* to
be emphatically clarified.

> We are talking about
> dependency resolution here. Pacman is not tied to systemd or whatever else you
> consider to be part of a "base installation". It shouldn't even matter what
> other packages the user is using as long as pacman's own deps are satisfied.
> For dependency resolution, Pacman's job is to determine what the user wants to
> install and then figure out what else the user needs to install it. All it
> needs to do that is the correct metadata, which is just a few extra words in
> some text files. That is better than implicit assumptions that may silently
> change in the future.

Right... I never suggested that pacman itself enforce a base
installation and I have no idea how you think I would go about doing
that anyway.

People using pacman as a package manager for, say, LFS or MSYS2 are more
than free to provide whatever installation instructions they want, and
make whatever implicit assumptions they like regarding a base
installation, and declare a PKGBUILD style policy suiting those assumptions.

Arch Linux is allowed to have different assumptions than pacman and
makepkg (and base-devel is an example of that).

>> I thought that was the point of suggesting that minimalist build chroots
>> potentially require base as well...
>
> A chroot that requires all of the base group is not minimal, it's bloated.
>
> It's like a lazy fruit vendor dumping apples, oranges, bananas, etc. into one
> giant bin because he can't be bothered to put them in separate bins (even
> though he has them, and it would be simple to do), then forcing customers who
> only want apples to buy big boxes of mixed fruit so that they can sort out the
> apples themselves and throw the rest of the fruit away (after paying for it).
The same logic applies to base-devel, most of which will not be used in
any given build. In fact, there are plenty of PKGBUILDs which use
nothing other than a package() function with calls to mkdir/cp/install.

TIL, Arch Linux is bloated and lazy. o_O

--
Eli Schwartz


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Should "base" packages be listed as dependencies?

tur-users mailing list
In reply to this post by Ralf Mardorf
On 03/23/2017 03:30 AM, Ralf Mardorf wrote:

> On Wed, 22 Mar 2017 22:31:34 -0400, Eli Schwartz via aur-general wrote:
>> nano (vi is the standard, and *I* don't even want to include that
>> because vim)
>
> For modern Linux distros nano has become a standard as well. What's bad
> with providing it by base? Linux isn't UNIX from the 70s. Also, I'm not using
> reiser, but what is so problematic with including reiserfsprogs? It at
> least was a Linux FS preferred as default FS for e.g. Suse a few
> years back? It's idiotic to discuss such trivialities. Some prefer it
> more old school others less old school. You are more old school but
> that's not enough, you even want to discuss what belongs to the old
> school.
Because you are either an idiot or being deliberately unhelpful?

You may not have realized, but the post you are replying to was arguing
for a defined minimally bootable runnable operating system. What Suse
used as a default FS is so completely irrelevant you should win an award...

Also, stop discriminating against emacs and Atom, which by the same
logic also belong in base because "stop being so old school".



(I really didn't realize that there was *anyone* who considered the
objectively horrible nano a standard. Almost any other editor ever,
aside from MS Notepad, is better in every respect.... Did anyone else
ever hear of this?)

--
Eli Schwartz


signature.asc (849 bytes) Download Attachment
12