Virtual provides for files in /var/log
Panu Matilainen
pmatilai at laiskiainen.org
Fri Jul 19 07:26:24 UTC 2013
On 07/18/2013 11:35 PM, Bill Nottingham wrote:
> Panu Matilainen (pmatilai at laiskiainen.org) said:
>> So... /var/log/messages is not guaranteed to be there even now,
>> because it depends on rsyslog configuration. So any packages which
>> cannot handle missing /var/log/messages are broken already in a
>> non-default (but probably not all that uncommon) config, and nobody
>> is crying out about that.
>
> Yes, it's just that if we're moving these packages from being broken in a
> non-default, administrator-configured configuration to being broken in the
> out-of-the-box configuration, it might be worthwhile to know that ahead of
> time, or know if there's a way to have them indicate that they now require
> the non-default configuration.
Yes, I understand the point behind this, its just that a pair of (file)
dependencies doesn't really make things "just work" either.
A file provide basically says "this package contains file X", but here
the presence of the promised file depends on a service configuration
*and* that the service is running (and has been so for some time).
The file presence could be ensured by doing 'touch /var/log/message' in
%post, but that doesn't make the file any more usable in the sense eg
hplip and lvm2 seem to expect.
Then there's the question (raised by Lennart) of what eg yum will do
with virtual file dependencies outside the "normal" paths, plus some
other (perhaps academic in this context) issues wrt virtual file
provides vs real files.
I guess all I'm saying that if dependencies are going to be used to
address the problem, a non-file dependency seems like a better option to
me. Perhaps "Provides: logfile(messages)" or such. That way depsolvers
will know full filelists will not be needed to resolve it, its easily
distinguishable and the semantics it represents can be clearly documented.
>
> I guess it's the equivalent of marking packages that don't work unless
> SELinux is enabled, or don't work unless the firewall is off. There are
> likely better ways to fix them.
Yeah... Log analyzers are one thing, but I dont know what eg hplip and
lvm2 are doing with the info scraped out of /var/log/messages, it seems
somewhat suspect at least.
- Panu -
More information about the devel
mailing list