[gentoo-dev] systemd profiles

[gentoo-dev] systemd profiles

[Jauhien Piatlicki]

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

Hi all,

I have a simple question: why do we have systemd subprofiles only in gnome and kde profiles?

Could we add systemd subprofiles also to default/linux/$arch/13.0/ and desktop (and any other profiles where it makes sense)?

Thanks for answers,
Jauhien


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] systemd profiles

[Alex Xu]

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

On 29/08/14 07:09 PM, Jauhien Piatlicki wrote:
> Hi all,
> 
> I have a simple question: why do we have systemd subprofiles only in gnome and kde profiles?
> 
> Could we add systemd subprofiles also to default/linux/$arch/13.0/ and desktop (and any other profiles where it makes sense)?
> 
> Thanks for answers,
> Jauhien
> 

long time question. no simple answer.

but basically, systemd is a feature, not a hardware profile. the best
architecture should allow one to mix and match features, like funtoo's
mixins. search gmane for more details.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] systemd profiles

[Rich Freeman]

On Fri, Aug 29, 2014 at 7:09 PM, Jauhien Piatlicki <jauhien@gentoo.org> wrote:
> Hi all,
>
> I have a simple question: why do we have systemd subprofiles only in gnome and kde profiles?
>
> Could we add systemd subprofiles also to default/linux/$arch/13.0/ and desktop (and any other profiles where it makes sense)?

I'm not sure systemd profiles actually make that much sense these
days.  To install systemd from a stage3 you basically just need to set
USE=systemd and do an emerge -uDN world.  We're actually getting close
to the point where you would pick an init system the way you pick a
kernel or cron implementation during install.

--
Rich

Re: [gentoo-dev] systemd profiles

[Jauhien Piatlicki]

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

Hi,

30.08.14 04:41, Rich Freeman написав(ла):
> On Fri, Aug 29, 2014 at 7:09 PM, Jauhien Piatlicki <jauhien@gentoo.org> wrote:
>> Hi all,
>>
>> I have a simple question: why do we have systemd subprofiles only in gnome and kde profiles?
>>
>> Could we add systemd subprofiles also to default/linux/$arch/13.0/ and desktop (and any other profiles where it makes sense)?
> 
> I'm not sure systemd profiles actually make that much sense these
> days.  To install systemd from a stage3 you basically just need to set
> USE=systemd and do an emerge -uDN world.  We're actually getting close
> to the point where you would pick an init system the way you pick a
> kernel or cron implementation during install.
> 
> --
> Rich
> 

that's good. Then I have another question: why systemd profile exists at all? As I see as consistent two possibilities:

1. no systemd profiles at all

2. systemd subprofile profile of default exists together with other profiles

---
Jauhien



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] systemd profiles

[J. Roeleveld]

On Friday, August 29, 2014 10:41:51 PM Rich Freeman wrote:
> On Fri, Aug 29, 2014 at 7:09 PM, Jauhien Piatlicki <jauhien@gentoo.org> 
wrote:
> > Hi all,
> > 
> > I have a simple question: why do we have systemd subprofiles only in gnome
> > and kde profiles?
> > 
> > Could we add systemd subprofiles also to default/linux/$arch/13.0/ and
> > desktop (and any other profiles where it makes sense)?
> I'm not sure systemd profiles actually make that much sense these
> days.  To install systemd from a stage3 you basically just need to set
> USE=systemd and do an emerge -uDN world.  We're actually getting close
> to the point where you would pick an init system the way you pick a
> kernel or cron implementation during install.

Not sure if this idea has been discussed before, but:
Wouldn't it be an idea to have a "virtual/init" which depends on 1 of:
- OpenRC
- Systemd
- ..... (whichever other one)

Put "virtual/init" in the @system-set.
Don't put either OpenRC or Systemd in the stage3-file. (Or have 2 stage3 
files, one with OpenRC and one with Systemd)
Then, during the install, the user has to choose one of these and install it.

The virtual could even use the "systemd" USE-flag to decide which one to use.

--
Joost

Re: [gentoo-dev] systemd profiles

[Michał Górny]

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

Dnia 2014-08-30, o godz. 13:27:08
"J. Roeleveld" <joost@antarean.org> napisał(a):

> On Friday, August 29, 2014 10:41:51 PM Rich Freeman wrote:
> > On Fri, Aug 29, 2014 at 7:09 PM, Jauhien Piatlicki <jauhien@gentoo.org> 
> wrote:
> > > Hi all,
> > > 
> > > I have a simple question: why do we have systemd subprofiles only in gnome
> > > and kde profiles?
> > > 
> > > Could we add systemd subprofiles also to default/linux/$arch/13.0/ and
> > > desktop (and any other profiles where it makes sense)?
> > I'm not sure systemd profiles actually make that much sense these
> > days.  To install systemd from a stage3 you basically just need to set
> > USE=systemd and do an emerge -uDN world.  We're actually getting close
> > to the point where you would pick an init system the way you pick a
> > kernel or cron implementation during install.
> 
> Not sure if this idea has been discussed before, but:
> Wouldn't it be an idea to have a "virtual/init" which depends on 1 of:

You mean our virtual/service-manager?

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] systemd profiles

[Rich Freeman]

On Sat, Aug 30, 2014 at 7:41 AM, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2014-08-30, o godz. 13:27:08
> "J. Roeleveld" <joost@antarean.org> napisał(a):
>>
>> Not sure if this idea has been discussed before, but:
>> Wouldn't it be an idea to have a "virtual/init" which depends on 1 of:
>
> You mean our virtual/service-manager?
>

Michał is already well-aware of this one, but for general interest,
the main blocker to actually doing this is:
https://bugs.gentoo.org/show_bug.cgi?id=504116

Rich

Re: [gentoo-dev] systemd profiles

[Lars Wendler]

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

On Sat, 30 Aug 2014 08:03:10 -0400 Rich Freeman wrote:

>On Sat, Aug 30, 2014 at 7:41 AM, Michał Górny <mgorny@gentoo.org>
>wrote:
>> Dnia 2014-08-30, o godz. 13:27:08
>> "J. Roeleveld" <joost@antarean.org> napisał(a):
>>>
>>> Not sure if this idea has been discussed before, but:
>>> Wouldn't it be an idea to have a "virtual/init" which depends on 1
>>> of:
>>
>> You mean our virtual/service-manager?
>>
>
>Michał is already well-aware of this one, but for general interest,
>the main blocker to actually doing this is:
>https://bugs.gentoo.org/show_bug.cgi?id=504116

Which is really a shame that there's such slow progress. I already added
several patches to the blocking bugs but none was fixed meanwhile...

>Rich
>

Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC

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

Re: [gentoo-dev] systemd profiles

[Rich Freeman]

On Sat, Aug 30, 2014 at 8:55 AM, Lars Wendler <polynomial-c@gentoo.org> wrote:
> On Sat, 30 Aug 2014 08:03:10 -0400 Rich Freeman wrote:
>
>>On Sat, Aug 30, 2014 at 7:41 AM, Michał Górny <mgorny@gentoo.org>
>>wrote:
>>> Dnia 2014-08-30, o godz. 13:27:08
>>> "J. Roeleveld" <joost@antarean.org> napisał(a):
>>>>
>>>> Not sure if this idea has been discussed before, but:
>>>> Wouldn't it be an idea to have a "virtual/init" which depends on 1
>>>> of:
>>>
>>> You mean our virtual/service-manager?
>>>
>>
>>Michał is already well-aware of this one, but for general interest,
>>the main blocker to actually doing this is:
>>https://bugs.gentoo.org/show_bug.cgi?id=504116
>
> Which is really a shame that there's such slow progress. I already added
> several patches to the blocking bugs but none was fixed meanwhile...

A possible solution is to remove it in the next version of openrc, as
it is deprecated already.  Another solution is to ask the Council to
let somebody apply patches if the maintainer is unresponsive, set a
deadline, etc.

Since many of the packages are system packages letting them break
isn't really an option.

--
Rich

Re: [gentoo-dev] systemd profiles

[William Hubbs]

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

On Sat, Aug 30, 2014 at 09:45:23AM -0400, Rich Freeman wrote:
> A possible solution is to remove it in the next version of openrc, as
> it is deprecated already.  Another solution is to ask the Council to
> let somebody apply patches if the maintainer is unresponsive, set a
> deadline, etc.

The problem is  we have two different API's. Gentoo's API for tools that
do not involve booting, and OpenRC's API. In the past, they were
identical, but that isn't the case now.

That is why I haven't removed /etc/init.d/functions.sh. That is actually
part of OpenRC's public API now.

I can deprecate it. To do so, I would need to have it print out a
deprecation warning that would be wrong for Gentoo in the next release.

That warning would have to tell users to source
/lib*/rc/sh/functions.sh.

Thoughts?

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] systemd profiles

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/09/14 02:11 PM, William Hubbs wrote:
> On Sat, Aug 30, 2014 at 09:45:23AM -0400, Rich Freeman wrote:
>> A possible solution is to remove it in the next version of
>> openrc, as it is deprecated already.  Another solution is to ask
>> the Council to let somebody apply patches if the maintainer is
>> unresponsive, set a deadline, etc.
> 
> The problem is  we have two different API's. Gentoo's API for tools
> that do not involve booting, and OpenRC's API. In the past, they
> were identical, but that isn't the case now.
> 
> That is why I haven't removed /etc/init.d/functions.sh. That is
> actually part of OpenRC's public API now.
> 
> I can deprecate it. To do so, I would need to have it print out a 
> deprecation warning that would be wrong for Gentoo in the next
> release.
> 
> That warning would have to tell users to source 
> /lib*/rc/sh/functions.sh.
> 
> Thoughts?
> 
> William
> 


I thought the whole point of the gentoo-functions package was for it
to take over the /etc/init.d/functions.sh shortcut??

As far as I am aware (and i believe vapier will confirm),
/etc/init.d/functions.sh is and shall always remain part of the Gentoo
API, despite /etc/init.d/ now being the realm of openrc proper.  This
was part of the discussion over a year ago when the decision was made
to implement the pure-bash gentoo-functions.sh replacement in the
first place, and why that symlink didn't disappear back then.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF0EAREIAAYFAlQHW5YACgkQ2ugaI38ACPDligD9HBwLjLpgS/h9KQZzlBPCAENK
6K/X5Mnvi64fYINtebQA90Hu3GDJUHhOTG3it4ThoHphXdCd1Y3/TmutSnbDYDs=
=RJUs
-----END PGP SIGNATURE-----

Re: [gentoo-dev] systemd profiles

[William Hubbs]

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

On Wed, Sep 03, 2014 at 02:19:02PM -0400, Ian Stakenvicius wrote:
> I thought the whole point of the gentoo-functions package was for it
> to take over the /etc/init.d/functions.sh shortcut??
> 
> As far as I am aware (and i believe vapier will confirm),
> /etc/init.d/functions.sh is and shall always remain part of the Gentoo
> API, despite /etc/init.d/ now being the realm of openrc proper.  This
> was part of the discussion over a year ago when the decision was made
> to implement the pure-bash gentoo-functions.sh replacement in the
> first place, and why that symlink didn't disappear back then.
 
You are correct that that comment was made. However, later in the bug,
multiple folks made the observation that /etc is not the place for a
shell library, and there was no disagreement to that [1]. So the way I
read it we convinced vapier otherwise.

Also, the gentoo-functions.sh package went through several iterations before
it was stabled, and there were no complaints.

 William

 [1] https://bugs.gentoo.org/373219

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] systemd profiles

[Rich Freeman]

On Wed, Sep 3, 2014 at 2:11 PM, William Hubbs <williamh@gentoo.org> wrote:
>
> I can deprecate it. To do so, I would need to have it print out a
> deprecation warning that would be wrong for Gentoo in the next release.
>
> That warning would have to tell users to source
> /lib*/rc/sh/functions.sh.

I don't have a problem with openrc supplying an API.  However, that
API should be limited to openrc-specific functions, and it really
shouldn't be used by anything else except for stuff like
starting/stopping services, determining the runlevel, or other
openrc-ish things.  It shouldn't be used for utility functions.

It would probably make more sense to have a generic init-agnostic
Gentoo wrapper in /lib, and then have it call the appropriate
openrc/systemd/whatever functions based on how the system is
configured.

If the decision is to stick that generic Gentoo script in /etc I don't
think it is the end of the world, but it probably shouldn't be
provided by openrc.  In general we shouldn't have dependencies on an
init system unless the package is actually interacting with the init
system.

--
Rich

[gentoo-dev] Re: systemd profiles

[Steven J. Long]

On Wed, Sep 03, 2014 at 03:27:15PM -0400, Rich Freeman wrote:
> On Wed, Sep 3, 2014 at 2:11 PM, William Hubbs <williamh@gentoo.org> wrote:
> >
> > I can deprecate it. To do so, I would need to have it print out a
> > deprecation warning that would be wrong for Gentoo in the next release.
> >
> > That warning would have to tell users to source
> > /lib*/rc/sh/functions.sh.
> 
> I don't have a problem with openrc supplying an API.  However, that
> API should be limited to openrc-specific functions, and it really
> shouldn't be used by anything else except for stuff like
> starting/stopping services, determining the runlevel, or other
> openrc-ish things.  It shouldn't be used for utility functions.

Well the reason the util API is provided by openrc is so that _programs_
running at init time can provide the output users love, as well as scripts.
Yes they're trivial functionality and many a shell scripter has their own
variant, but equally it makes sense to have one C wrapper, with a lib
API, and not duplicate the code. Hence my strong disagreement with the
removal of the API, which was reverted a few weeks after it was committed
when it turned out to have a consumer after all.

Obviously that fits your description of init-specific, and I don't have
any issue at all with the shell lib being in one place either: it makes
total sense, in the same way as having the lib API in openrc for init
programs does.

> It would probably make more sense to have a generic init-agnostic
> Gentoo wrapper in /lib, and then have it call the appropriate
> openrc/systemd/whatever functions based on how the system is
> configured.

Most usage is of really trivial stuff, so I don't think that should
rely on any init-system at all: it's basic sh, minimal when done well.

> If the decision is to stick that generic Gentoo script in /etc I don't
> think it is the end of the world,

Not at all: a sh file is simple text after all, unless ofc it's been
complexified by someone who doesn't grok sh and obfuscated with insane
bracing. The discussion was had a long time ago about the canonical
location, which is separate from which package provides it: personally
I'd do what vapier said and put it back in baselayout where it belongs.

I don't care where it goes personally, so long as it's available at init
and not in some nubEnterpriseFactory location, but I'd defer to vapier
and UberLord if it were my call. I can see the reasoning that /etc
provides for site-specific customisation, as well as config updates, in
a location admins expect to customise, and indeed backup more strictly
than some places.

> but it probably shouldn't be provided by openrc.

>  In general we shouldn't have dependencies on an
> init system unless the package is actually interacting with the init
> system.

Agreed.

Regards,
steveL
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] systemd profiles

[J. Roeleveld]

On Saturday, August 30, 2014 01:41:26 PM Michał Górny wrote:
> Dnia 2014-08-30, o godz. 13:27:08
> 
> "J. Roeleveld" <joost@antarean.org> napisał(a):
> > On Friday, August 29, 2014 10:41:51 PM Rich Freeman wrote:
> > > On Fri, Aug 29, 2014 at 7:09 PM, Jauhien Piatlicki <jauhien@gentoo.org>
> > 
> > wrote:
> > > > Hi all,
> > > > 
> > > > I have a simple question: why do we have systemd subprofiles only in
> > > > gnome
> > > > and kde profiles?
> > > > 
> > > > Could we add systemd subprofiles also to default/linux/$arch/13.0/ and
> > > > desktop (and any other profiles where it makes sense)?
> > > 
> > > I'm not sure systemd profiles actually make that much sense these
> > > days.  To install systemd from a stage3 you basically just need to set
> > > USE=systemd and do an emerge -uDN world.  We're actually getting close
> > > to the point where you would pick an init system the way you pick a
> > > kernel or cron implementation during install.
> > 
> > Not sure if this idea has been discussed before, but:
> 
> > Wouldn't it be an idea to have a "virtual/init" which depends on 1 of:
> You mean our virtual/service-manager?

Yes, couldn't quickly find it.

--
Joost