12:24 p.m.
Hello,
I've been doing some testing of F32 and was curious about something. I have a
kickstart file that just installs @core to be a minimal system. While looking
over the resulting system, there are fonts, wayland, gtk3 and others. Is this
intentional? The system probably doesn't have everything that's needs to
function as a desktop. Why are all these installed by @core?
-Steve
12:55 p.m.
On Thu, 2020-04-02 at 13:24 -0400, Steve Grubb wrote:
Hello,
I've been doing some testing of F32 and was curious about something. I have a
kickstart file that just installs @core to be a minimal system. While looking
over the resulting system, there are fonts, wayland, gtk3 and others. Is this
intentional? The system probably doesn't have everything that's needs to
function as a desktop. Why are all these installed by @core?
Because you're installing with weak dependencies enabled, and one of
them is bringing in gtk3. I haven't tried to figure out which one, I
just know dnf install --setopt=install_weak_deps=false @core didn't try
to pull in libX11.
- ajax
1:49 p.m.
On Thursday, April 2, 2020 1:55:10 PM EDT Adam Jackson wrote:
On Thu, 2020-04-02 at 13:24 -0400, Steve Grubb wrote:
> Hello,
>
> I've been doing some testing of F32 and was curious about something. I
> have a kickstart file that just installs @core to be a minimal system.
> While looking over the resulting system, there are fonts, wayland, gtk3
> and others. Is this intentional? The system probably doesn't have
> everything that's needs to function as a desktop. Why are all these
> installed by @core?
Because you're installing with weak dependencies enabled, and one of
them is bringing in gtk3.
Thanks for the pointer. Investigating that:
$ rpm --query --recommends gtk3
dconf(x86-64)
Looking at that
https://src.fedoraproject.org/rpms/dconf/blob/master/f/dconf.spec
There is a build requires on gtk-doc. But nowhere do I see gtk3 as a
recommends.
-Steve
I haven't tried to figure out which one, I
just know dnf install --setopt=install_weak_deps=false @core didn't try
to pull in libX11.
- ajax
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.or
g
1:59 p.m.
On Thu, Apr 2, 2020 at 2:50 PM Steve Grubb <sgrubb(a)redhat.com> wrote:
On Thursday, April 2, 2020 1:55:10 PM EDT Adam Jackson wrote:
> On Thu, 2020-04-02 at 13:24 -0400, Steve Grubb wrote:
>
> > Hello,
> >
> > I've been doing some testing of F32 and was curious about something. I
> > have a kickstart file that just installs @core to be a minimal system.
> > While looking over the resulting system, there are fonts, wayland, gtk3
> > and others. Is this intentional? The system probably doesn't have
> > everything that's needs to function as a desktop. Why are all these
> > installed by @core?
>
>
> Because you're installing with weak dependencies enabled, and one of
> them is bringing in gtk3.
Thanks for the pointer. Investigating that:
$ rpm --query --recommends gtk3
dconf(x86-64)
Looking at that
https://src.fedoraproject.org/rpms/dconf/blob/master/f/dconf.spec
There is a build requires on gtk-doc. But nowhere do I see gtk3 as a
recommends.
You got that backwards. You listed the things that gtk3 has as a Recommends:
Try `dnf repoquery --whatrecommends gtk3`
java-11-openjdk-1:11.0.6.10-0.fc32.x86_64
java-11-openjdk-slowdebug-1:11.0.6.10-0.fc32.x86_64
java-latest-openjdk-1:13.0.2.8-1.rolling.fc32.x86_64
java-latest-openjdk-slowdebug-1:13.0.2.8-1.rolling.fc32.x86_64
solaar-0:1.0.2-0.1.rc1.20200322git563ef0d.fc32.noarch
That said, I think gtk3 is always part of the standard installation
because it's needed by Anaconda.
2:02 p.m.
On Thu, 2020-04-02 at 14:59 -0400, Stephen Gallagher wrote:
On Thu, Apr 2, 2020 at 2:50 PM Steve Grubb <sgrubb(a)redhat.com>
wrote:
> On Thursday, April 2, 2020 1:55:10 PM EDT Adam Jackson wrote:
> > On Thu, 2020-04-02 at 13:24 -0400, Steve Grubb wrote:
> >
> > > Hello,
> > >
> > > I've been doing some testing of F32 and was curious about something.
I
> > > have a kickstart file that just installs @core to be a minimal system.
> > > While looking over the resulting system, there are fonts, wayland, gtk3
> > > and others. Is this intentional? The system probably doesn't have
> > > everything that's needs to function as a desktop. Why are all these
> > > installed by @core?
> >
> > Because you're installing with weak dependencies enabled, and one of
> > them is bringing in gtk3.
>
> Thanks for the pointer. Investigating that:
>
> $ rpm --query --recommends gtk3
> dconf(x86-64)
>
> Looking at that
> https://src.fedoraproject.org/rpms/dconf/blob/master/f/dconf.spec
>
> There is a build requires on gtk-doc. But nowhere do I see gtk3 as a
> recommends.
>
You got that backwards. You listed the things that gtk3 has as a Recommends:
Try `dnf repoquery --whatrecommends gtk3`
java-11-openjdk-1:11.0.6.10-0.fc32.x86_64
java-11-openjdk-slowdebug-1:11.0.6.10-0.fc32.x86_64
java-latest-openjdk-1:13.0.2.8-1.rolling.fc32.x86_64
java-latest-openjdk-slowdebug-1:13.0.2.8-1.rolling.fc32.x86_64
solaar-0:1.0.2-0.1.rc1.20200322git563ef0d.fc32.noarch
That said, I think gtk3 is always part of the standard installation
because it's needed by Anaconda.
The GUI anaconda requirements should be split into anaconda-gui and
that shouldn't be part of a minimal install. In fact I don't think
anaconda should be pulled into an @core install at all, offhand.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2:05 p.m.
On Thu, Apr 2, 2020 at 8:03 PM Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
On Thu, 2020-04-02 at 14:59 -0400, Stephen Gallagher wrote:
> On Thu, Apr 2, 2020 at 2:50 PM Steve Grubb <sgrubb(a)redhat.com> wrote:
> > On Thursday, April 2, 2020 1:55:10 PM EDT Adam Jackson wrote:
> > > On Thu, 2020-04-02 at 13:24 -0400, Steve Grubb wrote:
> > >
> > > > Hello,
> > > >
> > > > I've been doing some testing of F32 and was curious about
something. I
> > > > have a kickstart file that just installs @core to be a minimal
system.
> > > > While looking over the resulting system, there are fonts, wayland,
gtk3
> > > > and others. Is this intentional? The system probably doesn't
have
> > > > everything that's needs to function as a desktop. Why are all
these
> > > > installed by @core?
> > >
> > > Because you're installing with weak dependencies enabled, and one of
> > > them is bringing in gtk3.
> >
> > Thanks for the pointer. Investigating that:
> >
> > $ rpm --query --recommends gtk3
> > dconf(x86-64)
> >
> > Looking at that
> > https://src.fedoraproject.org/rpms/dconf/blob/master/f/dconf.spec
> >
> > There is a build requires on gtk-doc. But nowhere do I see gtk3 as a
> > recommends.
> >
>
> You got that backwards. You listed the things that gtk3 has as a Recommends:
>
> Try `dnf repoquery --whatrecommends gtk3`
>
> java-11-openjdk-1:11.0.6.10-0.fc32.x86_64
> java-11-openjdk-slowdebug-1:11.0.6.10-0.fc32.x86_64
> java-latest-openjdk-1:13.0.2.8-1.rolling.fc32.x86_64
> java-latest-openjdk-slowdebug-1:13.0.2.8-1.rolling.fc32.x86_64
> solaar-0:1.0.2-0.1.rc1.20200322git563ef0d.fc32.noarch
>
>
> That said, I think gtk3 is always part of the standard installation
> because it's needed by Anaconda.
The GUI anaconda requirements should be split into anaconda-gui and
that shouldn't be part of a minimal install. In fact I don't think
anaconda should be pulled into an @core install at all, offhand.
It shouldn't be listed in @core, it would be pulled in by the bits of
the installer process that needs it.
2:13 p.m.
On Thu, 2020-04-02 at 20:05 +0100, Peter Robinson wrote:
On Thu, Apr 2, 2020 at 8:03 PM Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
> On Thu, 2020-04-02 at 14:59 -0400, Stephen Gallagher wrote:
> > On Thu, Apr 2, 2020 at 2:50 PM Steve Grubb <sgrubb(a)redhat.com> wrote:
> > > On Thursday, April 2, 2020 1:55:10 PM EDT Adam Jackson wrote:
> > > > On Thu, 2020-04-02 at 13:24 -0400, Steve Grubb wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I've been doing some testing of F32 and was curious about
something. I
> > > > > have a kickstart file that just installs @core to be a minimal
system.
> > > > > While looking over the resulting system, there are fonts,
wayland, gtk3
> > > > > and others. Is this intentional? The system probably doesn't
have
> > > > > everything that's needs to function as a desktop. Why are
all these
> > > > > installed by @core?
> > > >
> > > > Because you're installing with weak dependencies enabled, and one
of
> > > > them is bringing in gtk3.
> > >
> > > Thanks for the pointer. Investigating that:
> > >
> > > $ rpm --query --recommends gtk3
> > > dconf(x86-64)
> > >
> > > Looking at that
> > > https://src.fedoraproject.org/rpms/dconf/blob/master/f/dconf.spec
> > >
> > > There is a build requires on gtk-doc. But nowhere do I see gtk3 as a
> > > recommends.
> > >
> >
> > You got that backwards. You listed the things that gtk3 has as a Recommends:
> >
> > Try `dnf repoquery --whatrecommends gtk3`
> >
> > java-11-openjdk-1:11.0.6.10-0.fc32.x86_64
> > java-11-openjdk-slowdebug-1:11.0.6.10-0.fc32.x86_64
> > java-latest-openjdk-1:13.0.2.8-1.rolling.fc32.x86_64
> > java-latest-openjdk-slowdebug-1:13.0.2.8-1.rolling.fc32.x86_64
> > solaar-0:1.0.2-0.1.rc1.20200322git563ef0d.fc32.noarch
> >
> >
> > That said, I think gtk3 is always part of the standard installation
> > because it's needed by Anaconda.
>
> The GUI anaconda requirements should be split into anaconda-gui and
> that shouldn't be part of a minimal install. In fact I don't think
> anaconda should be pulled into an @core install at all, offhand.
It shouldn't be listed in @core, it would be pulled in by the bits of
the installer process that needs it.
Right, and it isn't listed in @core. Stephen seems to be saying it's
normal that @core would pull in anaconda somehow, but I don't think it
is.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2:25 p.m.
On Thursday, April 2, 2020 2:59:33 PM EDT Stephen Gallagher wrote:
On Thu, Apr 2, 2020 at 2:50 PM Steve Grubb <sgrubb(a)redhat.com>
wrote:
> On Thursday, April 2, 2020 1:55:10 PM EDT Adam Jackson wrote:
> > On Thu, 2020-04-02 at 13:24 -0400, Steve Grubb wrote:
> > > I've been doing some testing of F32 and was curious about something.
> > > I have a kickstart file that just installs @core to be a minimal
> > > system. While looking over the resulting system, there are fonts,
> > > wayland, gtk3 and others. Is this intentional? The system probably
> > > doesn't have everything that's needs to function as a desktop.
Why
> > > are all these installed by @core?
> >
> > Because you're installing with weak dependencies enabled, and one of
> > them is bringing in gtk3.
>
> Thanks for the pointer. Investigating that:
>
> $ rpm --query --recommends gtk3
> dconf(x86-64)
>
> Looking at that
> https://src.fedoraproject.org/rpms/dconf/blob/master/f/dconf.spec
>
> There is a build requires on gtk-doc. But nowhere do I see gtk3 as a
> recommends.
>
You got that backwards. You listed the things that gtk3 has as a
Recommends:
Try `dnf repoquery --whatrecommends gtk3`
java-11-openjdk-1:11.0.6.10-0.fc32.x86_64
java-11-openjdk-slowdebug-1:11.0.6.10-0.fc32.x86_64
java-latest-openjdk-1:13.0.2.8-1.rolling.fc32.x86_64
java-latest-openjdk-slowdebug-1:13.0.2.8-1.rolling.fc32.x86_64
solaar-0:1.0.2-0.1.rc1.20200322git563ef0d.fc32.noarch
That said, I think gtk3 is always part of the standard installation
because it's needed by Anaconda.
Hmm. I'm doing a text mode install via kickstart.
skipx
text
Anaconda itself is not installed. Neither are any form of java or solaar. And
if anaconda needed it, I could see it maybe being in the temporary image it
uses to do the install, but not the final one. I also don't remember desktop
packages being picked up in the past when kickstarting a minimal image.
-Steve
7:15 a.m.
On Thu, Apr 02, 2020 at 02:59:33PM -0400, Stephen Gallagher wrote:
> > On Thu, 2020-04-02 at 13:24 -0400, Steve Grubb wrote:
> >
> > > Hello,
> > >
> > > I've been doing some testing of F32 and was curious about something.
I
> > > have a kickstart file that just installs @core to be a minimal system.
> > > While looking over the resulting system, there are fonts, wayland, gtk3
> > > and others. Is this intentional? The system probably doesn't have
> > > everything that's needs to function as a desktop. Why are all these
> > > installed by @core?
[...]
That said, I think gtk3 is always part of the standard installation
because it's needed by Anaconda.
Anaconda is not pulled in by @core.
The dependency chain from @core to gtk3 and fonts actually goes from
gnupg2, required by dnf, which recommends pinentry, which requires
libsecret-1.so.0()(64bit), which then recommends gnome-keyring, which
requires /usr/libexec/gcr-ssh-askpass, which comes from gcr, which
requires libgtk-3.so.0()(64bit) and libpango-1.0.so.0()(64bit).
It can also be demonstrated with
$ podman run --rm -ti registry.fedoraproject.org/fedora:32 dnf reinstall gnupg2
Running dnf install with --setopt=install_weak_deps=false (or
in kickstart %packages --excludeWeakdeps) removes those extra
82 packages from the transaction.
--
Jan Pazdziora
Product Owner, Platform Security Readiness, Red Hat
7:25 a.m.
On Fri, Apr 3, 2020 at 2:18 PM Jan Pazdziora <jpazdziora(a)redhat.com> wrote:
The dependency chain from @core to gtk3 and fonts actually goes from
gnupg2, required by dnf, which recommends pinentry, which requires
libsecret-1.so.0()(64bit), which then recommends gnome-keyring, which
requires /usr/libexec/gcr-ssh-askpass, which comes from gcr, which
requires libgtk-3.so.0()(64bit) and libpango-1.0.so.0()(64bit).
I added the libsecret -> gnome-keyring recommends due to
https://bugzilla.redhat.com/show_bug.cgi?id=1725412 but perhaps it's best
to revert this change and move the gnome-keyring recommends to geary
instead.
Any thoughts?
--
Kalev
8:12 a.m.
On Fri, Apr 03, 2020 at 02:25:36PM +0200, Kalev Lember wrote:
On Fri, Apr 3, 2020 at 2:18 PM Jan Pazdziora
<jpazdziora(a)redhat.com> wrote:
> The dependency chain from @core to gtk3 and fonts actually goes from
> gnupg2, required by dnf, which recommends pinentry, which requires
> libsecret-1.so.0()(64bit), which then recommends gnome-keyring, which
> requires /usr/libexec/gcr-ssh-askpass, which comes from gcr, which
> requires libgtk-3.so.0()(64bit) and libpango-1.0.so.0()(64bit).
>
I added the libsecret -> gnome-keyring recommends due to
https://bugzilla.redhat.com/show_bug.cgi?id=1725412 but perhaps it's best
to revert this change and move the gnome-keyring recommends to geary
instead.
Any thoughts?
If geary cannot work without a libsecret server, then geary should
hard-require one of them. It seems that libsecret library is perfectly fine
without a server (although it makes the client pointless) as pinentry
demonstrates.
I understand that the same issue can repeat with any libsecret application that
does not survive libsecret failure and centerilizing the dependendency at one
place sounds right. But it indeed looks like the failure is in the application.
Maybe libsecret spec could provide an empty libsecret-never-fail subpackage
that would hard-require a libsecret server and the applications like geary would
require that subpackage. (Alternatively libsecret-devel could provide a RPM
macro that the applications use to add a direct dependency on a server.) But
this abstractions is quite academic provided the only libsecret server in
Fedora is gnome-keyring.
-- Petr
11:55 p.m.
On Fri, Apr 03, 2020 at 03:12:35PM +0200, Petr Pisar wrote:
Maybe libsecret spec could provide an empty libsecret-never-fail subpackage
that would hard-require a libsecret server and the applications like geary would
require that subpackage. (Alternatively libsecret-devel could provide a RPM
macro that the applications use to add a direct dependency on a server.) But
this abstractions is quite academic provided the only libsecret server in
Fedora is gnome-keyring.
I wouldn't focus on a particular package because the situation can
repeat with any other package in the future, and would make the question
more generic.
Is it expected, are we OK with the fact, that with default settings
of weak dependencies enabled in dnf and anaconda, installing @group
can eventually pull in way more packages than originally listed
in the group, beyond the hard dependencies? Should following the weak
dependencies be a boolean yes/no setting, or should it be a score and
should the resolver have an option to favour weak dependencies when
resolving the first level of depenencies from the original package
list but decrease (perhaps radically) favouring them in next and
next-next-levels, potentially even taking into account if the
intermediate dependencies were explicit ones or implicit libraries?
In other words, if I list packages A, B, C in transaction, I might
want to have their weak dependencies thrown onto the system as well.
But if A requires libX.so and libY.so, and package X requires G and
that has weak dependency on K, I might not care about K.
If I explicitly say I want G, then again, sure, give me K as well.
--
Jan Pazdziora
Product Owner, Platform Security Readiness, Red Hat
10:24 a.m.
On Sat, 2020-04-04 at 06:55 +0200, Jan Pazdziora wrote:
On Fri, Apr 03, 2020 at 03:12:35PM +0200, Petr Pisar wrote:
> Maybe libsecret spec could provide an empty libsecret-never-fail subpackage
> that would hard-require a libsecret server and the applications like geary would
> require that subpackage. (Alternatively libsecret-devel could provide a RPM
> macro that the applications use to add a direct dependency on a server.) But
> this abstractions is quite academic provided the only libsecret server in
> Fedora is gnome-keyring.
I wouldn't focus on a particular package because the situation can
repeat with any other package in the future, and would make the question
more generic.
Is it expected, are we OK with the fact, that with default settings
of weak dependencies enabled in dnf and anaconda, installing @group
can eventually pull in way more packages than originally listed
in the group, beyond the hard dependencies? Should following the weak
dependencies be a boolean yes/no setting, or should it be a score and
should the resolver have an option to favour weak dependencies when
resolving the first level of depenencies from the original package
list but decrease (perhaps radically) favouring them in next and
next-next-levels, potentially even taking into account if the
intermediate dependencies were explicit ones or implicit libraries?
In other words, if I list packages A, B, C in transaction, I might
want to have their weak dependencies thrown onto the system as well.
But if A requires libX.so and libY.so, and package X requires G and
that has weak dependency on K, I might not care about K.
If I explicitly say I want G, then again, sure, give me K as well.
Boy, I don't know about you but I sure am looking forward to taking a
degree in math to understand why packages are or are not installed!
(you know, as opposed to the whole thing with the rubber chicken and
the pulley that I do right now)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
10:46 a.m.
On Tuesday, April 7, 2020 11:24:28 AM EDT Adam Williamson wrote:
On Sat, 2020-04-04 at 06:55 +0200, Jan Pazdziora wrote:
> On Fri, Apr 03, 2020 at 03:12:35PM +0200, Petr Pisar wrote:
> > Maybe libsecret spec could provide an empty libsecret-never-fail
> > subpackage that would hard-require a libsecret server and the
> > applications like geary would require that subpackage. (Alternatively
> > libsecret-devel could provide a RPM macro that the applications use to
> > add a direct dependency on a server.) But this abstractions is quite
> > academic provided the only libsecret server in Fedora is
> > gnome-keyring.
>
> I wouldn't focus on a particular package because the situation can
> repeat with any other package in the future, and would make the question
> more generic.
>
> Is it expected, are we OK with the fact, that with default settings
> of weak dependencies enabled in dnf and anaconda, installing @group
> can eventually pull in way more packages than originally listed
> in the group, beyond the hard dependencies? Should following the weak
> dependencies be a boolean yes/no setting, or should it be a score and
> should the resolver have an option to favour weak dependencies when
> resolving the first level of depenencies from the original package
> list but decrease (perhaps radically) favouring them in next and
> next-next-levels, potentially even taking into account if the
> intermediate dependencies were explicit ones or implicit libraries?
>
> In other words, if I list packages A, B, C in transaction, I might
> want to have their weak dependencies thrown onto the system as well.
> But if A requires libX.so and libY.so, and package X requires G and
> that has weak dependency on K, I might not care about K.
>
> If I explicitly say I want G, then again, sure, give me K as well.
Boy, I don't know about you but I sure am looking forward to taking a
degree in math to understand why packages are or are not installed!
I think out of this whole experience, there might need to be a rule that any
weak depency added to a package in @Core should not result in pulling is a
nearly working desktop. Maybe that should also be extended to @Base?
-Steve
1:40 p.m.
On Tue, Apr 07, 2020 at 11:46:20AM -0400, Steve Grubb wrote:
I think out of this whole experience, there might need to be a rule
that any
weak depency added to a package in @Core should not result in pulling is a
nearly working desktop. Maybe that should also be extended to @Base?
That's pretty much what the reporting produced by Minimization
Objective [1] is looking at. There is no automatic enforcement though.
[1] https://docs.fedoraproject.org/en-US/minimization/
Zbyszek
2:21 a.m.
On Fri, Apr 03, 2020 at 02:25:36PM +0200, Kalev Lember wrote:
On Fri, Apr 3, 2020 at 2:18 PM Jan Pazdziora
<jpazdziora(a)redhat.com> wrote:
> The dependency chain from @core to gtk3 and fonts actually goes from
> gnupg2, required by dnf, which recommends pinentry, which requires
> libsecret-1.so.0()(64bit), which then recommends gnome-keyring, which
> requires /usr/libexec/gcr-ssh-askpass, which comes from gcr, which
> requires libgtk-3.so.0()(64bit) and libpango-1.0.so.0()(64bit).
>
I added the libsecret -> gnome-keyring recommends due to
https://bugzilla.redhat.com/show_bug.cgi?id=1725412 but perhaps it's best
to revert this change
Yes, please.
and move the gnome-keyring recommends to geary instead.
Or simply make geary not fail if that happens? (Sounds like the fix would be in
libsecret, but I didn't look at the details).
One of the great things about dbus ipc is that we can have a loose coupling
between packages. A program should never ever abort because some other dbus
service is not active.
Any thoughts?
Alternatively, rich dependencies could be used somewhere: recommend
gnome-keyring only if gnome-shell is present or something like that.
Zbyszek
7:42 a.m.
On 4/4/20 09:21, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Apr 03, 2020 at 02:25:36PM +0200, Kalev Lember wrote:
> I added the libsecret -> gnome-keyring recommends due to
> https://bugzilla.redhat.com/show_bug.cgi?id=1725412 but perhaps it's best
> to revert this change
Yes, please.
OK, I went ahead and did that:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-bec4522056
Thanks everybody!
--
Kalev
1:26 p.m.
Le jeudi 02 avril 2020 à 13:24 -0400, Steve Grubb a écrit :
Hello,
I've been doing some testing of F32 and was curious about something.
I have a
kickstart file that just installs @core to be a minimal system. While
looking
over the resulting system, there are fonts, wayland, gtk3 and others.
Is this
intentional? The system probably doesn't have everything that's needs
to
function as a desktop. Why are all these installed by @core?
Fonts are here because many users complained their minimal systems
(that needed fonts) did not work and they should not know they need to
put the fonts group in their kickstart, so packagers have been slowly
adding font deps everywhere just to get some peace.
(also the langpack initiative is yet another attempt to satisfy
everyone, that is likely to pull fonts on any system)
Lots of things use fonts server side, they’re not a desktop-only thing
(though on may argue the selection should be more minimal server-side)
--
Nicolas Mailhot
1501
days inactive
1506
days old
18 comments
11 participants
participants (11)
-
Adam Jackson -
Adam Williamson -
Jan Pazdziora -
Kalev Lember -
Nicolas Mailhot -
Peter Robinson -
Petr Pisar -
Samuel Sieb -
Stephen Gallagher -
Steve Grubb -
Zbigniew Jędrzejewski-Szmek