| 1 |
On Wed, 2019-04-24 at 08:42 -0400, Michael Orlitzky wrote: |
| 2 |
> On 4/24/19 8:24 AM, Michał Górny wrote: |
| 3 |
> > > which will still work (albeit with a warning) if you somehow manage not |
| 4 |
> > > to have virtual/tmpfiles installed. So, if it's important, I think we |
| 5 |
> > > could drop the RDEPEND="virtual/tmpfiles" from tmpfiles.eclass. |
| 6 |
> > |
| 7 |
> > Programs depend on tmpfiles being actually processed (either at install |
| 8 |
> > time or on boot). If you don't have the deps, you'll end up with |
| 9 |
> > missing directories, and programs that don't work out of the box. |
| 10 |
> > |
| 11 |
> |
| 12 |
> I get where you're coming from, but then shouldn't systemd.eclass also |
| 13 |
> depend on systemd for its systemd-tmpfiles implementation? Otherwise, |
| 14 |
> you can make exactly the same argument about systemd_tmpfiles_create(). |
| 15 |
> |
| 16 |
|
| 17 |
systemd.eclass has more than one purpose, and therefore such dep didn't |
| 18 |
belong there (ebuilds should take care of the dependencies when using |
| 19 |
tmpfiles logic from it). tmpfiles.eclass on the other hand has a single |
| 20 |
purpose, so we've solved the problem by adding an RDEPEND there. |
| 21 |
|
| 22 |
-- |
| 23 |
Best regards, |
| 24 |
Michał Górny |
Archives