On 4/26/19 10:54 AM, Michał Górny wrote:
In cases like that, adding RDEPEND=virtual/tmpfiles to the ebuild is a
better solution, because (a) the end result is exactly the same, (b) it
keeps the dependency out of the eclass, and (c) it localizes the
dependency to the place that needs it, namely
On Fri, 2019-04-26 at 10:26 -0400, Michael Orlitzky wrote:
> On 4/26/19 9:32 AM, Michał Górny wrote:
> > Whether it can be deleted is up to system's configuration. The current
> > solution works for majority of cases, including a. people who use
> > systemd or OpenRC, and set their systems to
On 4/26/19 9:32 AM, Michał Górny wrote:
>
> Whether it can be deleted is up to system's configuration. The current
> solution works for majority of cases, including a. people who use
> systemd or OpenRC, and set their systems to clean it up, and b. people
> who don't use either but don't clean
On Fri, 2019-04-26 at 09:24 -0400, Michael Orlitzky wrote:
> On 4/26/19 9:07 AM, Michał Górny wrote:
> > > I don't think so -- not if it needs that tmpfiles
> > > entry to be processed every reboot. Thus it should have its own RDEPEND
> > > on virtual/tmpfiles, making the one in the eclass
On 4/26/19 9:07 AM, Michał Górny wrote:
>
>> I don't think so -- not if it needs that tmpfiles
>> entry to be processed every reboot. Thus it should have its own RDEPEND
>> on virtual/tmpfiles, making the one in the eclass redundant.
>
> It doesn't need to be processed every reboot. It needs
On Fri, 2019-04-26 at 07:07 -0400, Michael Orlitzky wrote:
> On 4/26/19 12:53 AM, Michał Górny wrote:
> > > And the only reason we would need a transient directory created and/or
> > > cleaned-up is because one of those service managers is going to start a
> > > program that needs it. Two of them
On 4/26/19 7:07 AM, Michael Orlitzky wrote:
> Thus it should have its own RDEPEND on virtual/tmpfiles, making the
> one in the eclass redundant.
Correction, it should RDEPEND on either systemd or OpenRC. Having the
"tmpfiles" binary installed is not enough; it needs to be run every
reboot. The
On 4/26/19 12:53 AM, Michał Górny wrote:
>>
>> And the only reason we would need a transient directory created and/or
>> cleaned-up is because one of those service managers is going to start a
>> program that needs it. Two of them can use the tmpfiles mechanism, but
>> the others must handle it on
On Thu, 2019-04-25 at 17:42 -0400, Michael Orlitzky wrote:
> On 4/25/19 5:23 PM, Michał Górny wrote:
> > > What's wrong? You only need the effect of tmpfiles_process() if you're
> > > running systemd or OpenRC. If the user is running SysV-init and if the
> > > package also installs a SysV-init
On 4/25/19 5:23 PM, Michał Górny wrote:
>>
>> What's wrong? You only need the effect of tmpfiles_process() if you're
>> running systemd or OpenRC. If the user is running SysV-init and if the
>> package also installs a SysV-init script, then that init script is going
>> to have to create any
On Thu, Apr 25, 2019 at 5:26 PM Michał Górny wrote:
>
> On Thu, 2019-04-25 at 17:24 -0400, Mike Gilbert wrote:
> > On Tue, Apr 23, 2019 at 6:25 PM Zac Medico wrote:
> > > On 4/23/19 2:03 PM, Michael Orlitzky wrote:
> > > > We have two eclasses with almost-identical functions for handling
> > > >
On Thu, 2019-04-25 at 17:24 -0400, Mike Gilbert wrote:
> On Tue, Apr 23, 2019 at 6:25 PM Zac Medico wrote:
> > On 4/23/19 2:03 PM, Michael Orlitzky wrote:
> > > We have two eclasses with almost-identical functions for handling
> > > tmpfiles.d entries:
> > >
> > > 1. systemd.eclass
> > >
> >
On Tue, Apr 23, 2019 at 6:25 PM Zac Medico wrote:
>
> On 4/23/19 2:03 PM, Michael Orlitzky wrote:
> > We have two eclasses with almost-identical functions for handling
> > tmpfiles.d entries:
> >
> > 1. systemd.eclass
> >
> > a. systemd_dotmpfilesd
> > b. systemd_newtmpfilesd
> >
On Thu, 2019-04-25 at 16:49 -0400, Michael Orlitzky wrote:
> On 4/25/19 4:20 PM, Michał Górny wrote:
> > Wrong. tmpfiles_process() requires virtual/tmpfiles on any system,
> > including daemontools, bare minimal init and whatever. Keeping it
> > installed afterwards is a minor side effect, and
On 4/25/19 4:20 PM, Michał Górny wrote:
>
> Wrong. tmpfiles_process() requires virtual/tmpfiles on any system,
> including daemontools, bare minimal init and whatever. Keeping it
> installed afterwards is a minor side effect, and technical limitation of
> our dependency types (lack of
On Thu, 2019-04-25 at 16:07 -0400, Michael Orlitzky wrote:
> On 4/24/19 8:53 AM, Michał Górny wrote:
> > systemd.eclass has more than one purpose, and therefore such dep didn't
> > belong there (ebuilds should take care of the dependencies when using
> > tmpfiles logic from it). tmpfiles.eclass
On 4/24/19 8:53 AM, Michał Górny wrote:
>
> systemd.eclass has more than one purpose, and therefore such dep didn't
> belong there (ebuilds should take care of the dependencies when using
> tmpfiles logic from it). tmpfiles.eclass on the other hand has a single
> purpose, so we've solved the
On Wed, 2019-04-24 at 08:42 -0400, Michael Orlitzky wrote:
> On 4/24/19 8:24 AM, Michał Górny wrote:
> > > which will still work (albeit with a warning) if you somehow manage not
> > > to have virtual/tmpfiles installed. So, if it's important, I think we
> > > could drop the
On 4/24/19 8:24 AM, Michał Górny wrote:
>>
>> which will still work (albeit with a warning) if you somehow manage not
>> to have virtual/tmpfiles installed. So, if it's important, I think we
>> could drop the RDEPEND="virtual/tmpfiles" from tmpfiles.eclass.
>
> Programs depend on tmpfiles being
On Wed, 2019-04-24 at 07:56 -0400, Michael Orlitzky wrote:
> Likewise, the only function in tmpfiles.eclass that uses a systemd or
> opentmpfiles program is
>
> tmpfiles_process() {
> ...
> if type systemd-tmpfiles &> /dev/null; then
> systemd-tmpfiles --create "$@"
> elif
On 4/23/19 6:25 PM, Zac Medico wrote:
>
> Note that systemd.eclass is lighter on dependencies, which is why I
> chose it for the solution to bug 490676 [1] and bug 643386 [2] in the
> sys-apps/portage ebuilds.
>
> [1] https://bugs.gentoo.org/490676
> [2] https://bugs.gentoo.org/643386
>
I
On 4/23/19 2:03 PM, Michael Orlitzky wrote:
> We have two eclasses with almost-identical functions for handling
> tmpfiles.d entries:
>
> 1. systemd.eclass
>
> a. systemd_dotmpfilesd
> b. systemd_newtmpfilesd
> c. systemd_tmpfiles_create
>
> 2. tmpfiles.eclass
>
> a.
On Tue, Apr 23, 2019 at 5:03 PM Michael Orlitzky wrote:
>
> We have two eclasses with almost-identical functions for handling
> tmpfiles.d entries:
>
> 1. systemd.eclass
>
> a. systemd_dotmpfilesd
> b. systemd_newtmpfilesd
> c. systemd_tmpfiles_create
>
> 2. tmpfiles.eclass
>
>
We have two eclasses with almost-identical functions for handling
tmpfiles.d entries:
1. systemd.eclass
a. systemd_dotmpfilesd
b. systemd_newtmpfilesd
c. systemd_tmpfiles_create
2. tmpfiles.eclass
a. dotmpfiles
b. newtmpfiles
c. tmpfiles_process
The do/new
24 matches
Mail list logo
