| 1 |
On 17/11/16 12:22 PM, William Hubbs wrote: |
| 2 |
> On Thu, Nov 17, 2016 at 10:02:25AM -0500, Ian Stakenvicius wrote: |
| 3 |
>> On 17/11/16 01:03 AM, Michał Górny wrote: |
| 4 |
>>> On Wed, 16 Nov 2016 14:21:41 -0600 |
| 5 |
>>> William Hubbs <williamh@g.o> wrote: |
| 6 |
>>> |
| 7 |
>>>> On Wed, Nov 16, 2016 at 01:04:11PM -0500, Ian Stakenvicius wrote: |
| 8 |
>>>>> On 16/11/16 12:03 PM, William Hubbs wrote: |
| 9 |
>>>>>> On Wed, Nov 16, 2016 at 10:14:02AM -0500, Ian Stakenvicius wrote: |
| 10 |
>>>>>>> On 16/11/16 10:08 AM, William Hubbs wrote: |
| 11 |
>>>>>>>> opentmpfiles will be updated to install the service scripts which |
| 12 |
>>>>>>>> will be run when OpenRC boots a system. There is nothing for |
| 13 |
>>>>>>>> it to do if systemd is used to boot the system. |
| 14 |
>>>>>>>> |
| 15 |
>>>>>>>> William |
| 16 |
>>>>>>>> |
| 17 |
>>>>>>> |
| 18 |
>>>>>>> But there is something to do if openrc is used to boot the system and |
| 19 |
>>>>>>> systemd is the package providing tmpfiles.d processing via the virtual. |
| 20 |
>>>>>> |
| 21 |
>>>>>> The providers (opentmpfiles and systemd) will not block each other, so |
| 22 |
>>>>>> the only way this will happen is if you have openrc and systemd |
| 23 |
>>>>>> installed then forcefully remove opentmpfiles. I think you would not |
| 24 |
>>>>>> want to do that until you are ready to migrate to booting with systemd. |
| 25 |
>>>>>> |
| 26 |
>>>>>> William |
| 27 |
>>>>>> |
| 28 |
>>>>> |
| 29 |
>>>>> I think I'm having a hard time getting across the issue here...: |
| 30 |
>>>>> |
| 31 |
>>>>> 1 - we will have a virtual/tmpfiles that will bring in EITHER systemd, |
| 32 |
>>>>> or opentmpfiles. |
| 33 |
>>>>> |
| 34 |
>>>>> 2 - openrc will NOT depend on opentmpfiles (nor virtual/tmpfiles) |
| 35 |
>>>>> |
| 36 |
>>>>> 3 - Applications that install stuff into /usr/lib/tmpfiles.d/ will |
| 37 |
>>>>> need to depend on virtual/tmpfiles in order to make sure that the |
| 38 |
>>>>> system has something installed that will process them at boot-time. |
| 39 |
>>>> |
| 40 |
>>>> Yes, this will be handled by an RDEPEND in the eclass. |
| 41 |
>>> |
| 42 |
>>> This is a wrong presumption. The eclass needs the virtual only for |
| 43 |
>>> pkg_postinst(). While RDEPEND is how we solve this now, it will no |
| 44 |
>>> longer be necessary in a future EAPI. |
| 45 |
>>> |
| 46 |
>> |
| 47 |
>> This makes sense to me as well -- which means every package that |
| 48 |
>> installs tmpfiles.d/ files should properly RDEPEND on the virtual on |
| 49 |
>> its own when the functionality arisen from those tmpfiles.d files is |
| 50 |
>> non-optional. |
| 51 |
> |
| 52 |
> Doesn't that bring into question the need of RDEPEND in the |
| 53 |
> eclass itself since it doesn't have a pkg_postinst function? I could |
| 54 |
> remove the rdepend from the eclass and add the following to the |
| 55 |
> documentation of the tmpfiles_process function: |
| 56 |
> |
| 57 |
> # Warning: Be sure that you rdepend on virtual/tmpfiles if you use this |
| 58 |
> # function in your ebuild. |
| 59 |
> |
| 60 |
> William |
| 61 |
> |
| 62 |
|
| 63 |
No I don't think so. The eclass uses these tmpfiles.d-processing |
| 64 |
commands in order to do its work, so therefore it needs to make sure |
| 65 |
the tools are there. As mgorny said earlier this RIGHT NOW means |
| 66 |
putting it in RDEPEND, but in a Future-EAPI it won't be RDEPEND but |
| 67 |
instead some other *DEPEND. |
| 68 |
|
| 69 |
Likewise, I don't think it's pertinent to inherit the eclass in order |
| 70 |
to ensure system runtime support of tmpfiles.d processing -- there's |
| 71 |
nothing to say that the eclass won't disappear in a year or two after |
| 72 |
all (because, say, the tmpfiles.d daemon starts using inotify and |
| 73 |
instantly processes any newly installed files, hypothetically) |
Archives