Adding ‘rottlog-service-type’ to ‘%base-services’

Adding ‘rottlog-service-type’ to ‘%base-services’

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

Hello Guix!

We discussed recently that we should add a ‘rottlog-service-type’
instance to ‘%base-services’.  It’s a trivial change that makes a lot of
sense to me.

It’s all fine but the problem is that it leads to a build failure of
etc.drv for those who were already adding ‘rottlog-service-type’ to
their services (because we end up with two instances of that service
type, both of which try to add /etc/rottlog.)

Perhaps that’s fine, and we can provide a news entry to let people now?

Incidentally, I think we should probably stop using GNU rottlog and
implement our own stuff: it wouldn’t be much work and would be much more
flexible (and we wouldn’t need that /etc/rottlog entry!).

Thoughts?

Ludo’.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 493 bytes --]

diff --git a/gnu/services/base.scm b/gnu/services/base.scm
index 8d9a563e2b..a0179c0259 100644
--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -2444,6 +2444,8 @@ to handle."
         (service guix-service-type)
         (service nscd-service-type)
 
+        (service rottlog-service-type)
+
         ;; The LVM2 rules are needed as soon as LVM2 or the device-mapper is
         ;; used, so enable them by default.  The FUSE and ALSA rules are
         ;; less critical, but handy.

Re: Adding ‘rottlog-service-type’ to ‘%base-services’

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 185 bytes --]

Ludo',

A good idea!

Ludovic Courtès 写道：
> Perhaps that’s fine, and we can provide a news entry to let 
> people now?

I agree that's fine.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Adding a %desktop-packages

[Joshua Branson]

This is slightly unrelated, but your email reminded me.

How about we add a %desktop-packages variable?  I remember reading a bug
report about possibly ungoogled-chromium or some package not working
properly, because the user did not install a font.  Perhaps if people
are using a %desktop, there should be some %desktop-packages that most
users will want installed by default.  Packages would include a web
browser, one system font, etc.

-- 
Joshua Branson Sent from Emacs and Gnus

P.S. I am subscribed to Guix-devel, please just respond via To:
guix-devel@gnu.org.  Thanks

Re: Adding a %desktop-packages

[Jan]

>This is slightly unrelated, but your email reminded me.
>
>How about we add a %desktop-packages variable?  I remember reading a
>bug
>report about possibly ungoogled-chromium or some package not working
>properly, because the user did not install a font.  Perhaps if people
>are using a %desktop, there should be some %desktop-packages that most
>users will want installed by default.  Packages would include a web
>browser, one system font, etc.
>
>-- 
>Joshua Branson Sent from Emacs and Gnus
>
>P.S. I am subscribed to Guix-devel, please just respond via To:
>address@hidden.  Thanks

Sounds good for me.
As a new user I found it annoying Icecat doesn't work by default.
IMO dejavu font should be an input of icecat or should be shipped with
the new %desktop-packages variable. Guix packages should just work out
of the box without the need for user to have any technical knowledge,
by doing so it can gain wider audience and popularity.


Jan Wielkiewicz

Re: Adding a %desktop-packages

[John Soo]

Hi there,

I am on board with providing some predefined lists of packages.

I raised the idea of providing smaller lists of packages that might go
well together instead of one large %desktop-packages. One reason to do
this, for instance, might be to not make someone who wants to use btrfs
always import the ext4 packages. Or not lock someone into using nettools
if they are using iproute2, etc.

Similarly, I think that many users, myself included, use a manifest file
to manage user packages. It would help to have finer grained
package lists so that the manifests could reuse them and not be
requiring system basics along with it.

What do you think?

- John

Re: Adding a %desktop-packages

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

Hello,

John Soo <jsoo1@asu.edu> ezt írta (időpont: 2020. ápr. 4., Szo 2:23):

> Hi there,
>
> I am on board with providing some predefined lists of packages.
>
> I raised the idea of providing smaller lists of packages that might go
> well together instead of one large %desktop-packages. One reason to do
> this, for instance, might be to not make someone who wants to use btrfs
> always import the ext4 packages. Or not lock someone into using nettools
> if they are using iproute2, etc.
>
> Similarly, I think that many users, myself included, use a manifest file
> to manage user packages. It would help to have finer grained
> package lists so that the manifests could reuse them and not be
> requiring system basics along with it.
>
> What do you think?
>

This is more in line with my thoughts. Also, if we have some of these fine
grained lists, it would be easy to provide collections of these, so we can
do both things, but in a more useful way.

>
> - John
>

Best regards,
g_bor

>

[-- Attachment #2: Type: text/html, Size: 1765 bytes --]

Re: Adding a %desktop-packages

[Brice Waegeneire]

Hello John,

On 2020-04-04 00:22, John Soo wrote:
> I raised the idea of providing smaller lists of packages that might go
> well together instead of one large %desktop-packages. One reason to do
> this, for instance, might be to not make someone who wants to use btrfs
> always import the ext4 packages. Or not lock someone into using 
> nettools
> if they are using iproute2, etc.

Regarding the file-system utils packages I'm working on a patch adding 
them
to the system profile based on the type of file-system defined. So, in 
the
end, `e2fsprogs`, `btrfs-progs` and such will be removed from 
%base-packages.

Also I've just submitted a patch[0] to split %base-packages as we talked
about on IRC a couple of weeks ago.

[0]: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=40423

- Brice

Re: Adding a %desktop-packages

[Ludovic Courtès]

Hi Joshua,

Joshua Branson <jbranso@dismail.de> skribis:

> This is slightly unrelated, but your email reminded me.
>
> How about we add a %desktop-packages variable?  I remember reading a bug
> report about possibly ungoogled-chromium or some package not working
> properly, because the user did not install a font.  Perhaps if people
> are using a %desktop, there should be some %desktop-packages that most
> users will want installed by default.  Packages would include a web
> browser, one system font, etc.

I think we should address the font issue.  A ‘%desktop-packages’ is
bound to never be satisfactory for anyone because it’s so subjective.

Thanks,
Ludo’.

Re: Adding a %desktop-packages

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]

Hello,

Ludovic Courtès <ludo@gnu.org> ezt írta (időpont: 2020. ápr. 6., Hét 10:02):

> Hi Joshua,
>
> Joshua Branson <jbranso@dismail.de> skribis:
>
> > This is slightly unrelated, but your email reminded me.
> >
> > How about we add a %desktop-packages variable?  I remember reading a bug
> > report about possibly ungoogled-chromium or some package not working
> > properly, because the user did not install a font.  Perhaps if people
> > are using a %desktop, there should be some %desktop-packages that most
> > users will want installed by default.  Packages would include a web
> > browser, one system font, etc.
>
> I think we should address the font issue.  A ‘%desktop-packages’ is
> bound to never be satisfactory for anyone because it’s so subjective.
>

Yes, this will not be statisfactory. However I believe that doing something
like this would be great:
define icecat-recommended
define browser-recommended icecat-recommended
define desktop-recommended (append desktop-recommended base-packages) with
deduplication.
I believe this approach has two merits:
We can provide an easy setup for those interested, and inspectable for
those who would like a working system, but want to configure certain aspects
And we can state the officially recommended software for a given task, so
that it is possible to focus efforts on these.

>
> Thanks,
> Ludo’.
>

Best regards,
g_bor

>
>

[-- Attachment #2: Type: text/html, Size: 2408 bytes --]