On 17/11/16 01:03 AM, Michał Górny wrote:
> On Wed, 16 Nov 2016 14:21:41 -0600
> William Hubbs <[email protected]> wrote:
> 
>> On Wed, Nov 16, 2016 at 01:04:11PM -0500, Ian Stakenvicius wrote:
>>> On 16/11/16 12:03 PM, William Hubbs wrote:  
>>>> On Wed, Nov 16, 2016 at 10:14:02AM -0500, Ian Stakenvicius wrote:  
>>>>> On 16/11/16 10:08 AM, William Hubbs wrote:  
>>>>>> opentmpfiles will be updated to install the service scripts which
>>>>>> will be run when OpenRC boots a system. There is nothing for
>>>>>> it to do if systemd is used to boot the system.
>>>>>>
>>>>>> William
>>>>>>  
>>>>>
>>>>> But there is something to do if openrc is used to boot the system and
>>>>> systemd is the package providing tmpfiles.d processing via the virtual.  
>>>>
>>>> The providers (opentmpfiles and systemd) will not block each other, so
>>>> the only way this will happen is if you have openrc and systemd
>>>> installed then forcefully remove opentmpfiles. I think you would not
>>>> want to do that until you are ready to migrate to booting with systemd.
>>>>
>>>> William
>>>>   
>>>
>>> I think I'm having a hard time getting across the issue here...:
>>>
>>> 1 - we will have a virtual/tmpfiles that will bring in EITHER systemd,
>>> or opentmpfiles.
>>>
>>> 2 - openrc will NOT depend on opentmpfiles (nor virtual/tmpfiles)
>>>
>>> 3 - Applications that install stuff into /usr/lib/tmpfiles.d/ will
>>> need to depend on virtual/tmpfiles in order to make sure that the
>>> system has something installed that will process them at boot-time.  
>>  
>>  Yes, this will be handled by an RDEPEND in the eclass.
> 
> This is a wrong presumption. The eclass needs the virtual only for
> pkg_postinst(). While RDEPEND is how we solve this now, it will no
> longer be necessary in a future EAPI.
> 

This makes sense to me as well -- which means every package that
installs tmpfiles.d/ files should properly RDEPEND on the virtual on
its own when the functionality arisen from those tmpfiles.d files is
non-optional.



Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to