[Dev] [RFC] OpenRC strategy
Megver83
megver83 at hyperbola.info
Wed Sep 13 20:03:00 GMT 2017
El 12/09/17 a las 23:48, Luke Shumaker escribió:
> On Tue, 12 Sep 2017 22:35:55 -0400,
> Megver83 wrote:
>>> - I'm locked in to using openrc-init as PID 1. OpenRC is designed in
>>> a way that splits PID 1 ("init") from the system manager (yay small
>>> modular programs!). That means you can actually use it with a
>>> number of different init programs, including sysvinit, busybox
>>> init, and since OpenRC 0.25, openrc-init. I should be able to use
>>> any of those as my init--hell, I should even be able to use systemd
>>> as my init.
>>
>> That's true, in fact it used to work with SysV in Parabola.
>
> Well yes, prior to OpenRC 0.25 it pretty much had to.
>
>> I'm beginning to miss it :'(
>
> Eh, I don't miss it, it was a pile of garbage, but I don't like that
> it was taken from me forcefully :)
>
>>>
>>> I propose that openrc be turned in to a split package, something like:
>>>
>>> pkgname=(openrc openrc-init openrc-sysvinit)
>>>
>>> package_openrc() {
>>> depends=(openrc-init)
>>> ...
>>> }
>>>
>>> package_openrc-init() {
>>> depends=(openrc)
>>> conflicts=(sysvinit)
>>> ...
>>> }
>>>
>>> package_openrc-sysvinit() {
>>> depends=(openrc sysvinit)
>>> provides=(openrc-init)
>>> conflicts=(openrc-init)
>>>
>>> install -Dm644 support/sysvinit/inittab "${pkgdir}/etc/inittab"
>>> }
>>>
>>> From there, there could be other [pcr] packages like
>>> 'openrc-busybox-init' to use busybox init. These packages would
>>> need to depends=(openrc), provides=(openrc-init), and probably
>>> conflicts=(openrc-init).
>>
>> Great idea, more options for PID 1, and one service manager.
>
> NB: I don't want to step on ovruni's toes, but I'm willing to do the
> above work on the openrc package if he's ok with it.
>
>>>
>>> Unfortunately, we don't have a good meta-package name to conflict
>>> with other packages that provide /bin/init.
>>
>> We could make one. Maybe 'initd'? or simply 'init'
>
> I'm in agreement with 'init'. Let's just wait on an agreement from
> ovruni (the openrc package maintainer). If he's in agreement, I'll
> add it to the next version of systemd-sysvcompat.
>
>>> - (not)systemd-udev should be a just as valid of a choice for udev as
>>> eudev is. In the past this was the case, via the udev-openrc
>>> package. If this package needs to be merged in to the notsystemd
>>> package, I am fine with that.
>>>
>> I don't think it's necessary, BTW you could try to remove from
>> notsystemd what it's already in other projects (e.g. logind, as we have
>> elogind). But the idea I liked it.
>
> The plan is for elogind to eventually merge to be part of notsystemd.
>
IDK if that's a good idea, maybe some users might want *only* elogind
and nothing else, not udev and all what notsystemd has (as of now).
--
~Megver83
https://megver83.ga/
SIP: megver83 at sip.linphone.org
IRC (Freenode): Megver83
XMPP: megver83 at jabjab.de
Tox: megver83 at toxme.io
GPG: 0x227CA7C556B2BA78
GNUSocial: @megver82 at quitter.cl
Diaspora*: megver83 at diasp.org
Pump: Megver83 at datamost.com
Friendica: megver83 at friendica.eu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 520 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20170913/212e804a/attachment.sig>
More information about the Dev
mailing list