[arch-general] Location of the pacman database

[Leonid Isaev]

Hi,

On Mon, Sep 15, 2014 at 07:32:51AM +0200, Tobias Hunger wrote:
> As I understand this, systemd expects daemons to deal with no settings in
> /etc and /var.

/var stores files, not settings. Most daemons will run OK with empty /var. But
what do you do with the files? Some kind of rsync gluework?

> I do not consider this a problem. When you use somebodies images you need
> to trust that person. I do not consider trusting the keys that person
> provides to be a problem.

But it is a problem which has already been discussed. If you have N images, and
1 has its key stolen, all N are in danger. So, it's not about (not) trusting
the developer.

> > > This is madness. I remember sometime ago there was a witchhunt
> > > against daemons that write to /etc (cups is the worst offender). So
> > > why is it OK for systemd to do so? I personally don't want systemd
> > > to come anywhere near my /etc. Please package the
> > > tmpfiles.d/sysusers stuff with virtkick or whatever, but not with
> > > pacman.
> 
> Any privileged process can mess with /etc at any time. With factory reset
> at least you get a pristine copy to compare the files in /etc against.

Sure, and then we call it malicious... What do you call pristine? The files
shipped on a livecd? Or an empty default configs shipped with daemons? So far,
there are only things like groups/users, but those are trivialities.

> Arch did embrace systemd, it should make it easy to use all its features. I
> am not proposing to enable them by default.

We already have enabled by default ldconfig.service enabled,
systemd-update-done.service, etc, which messed a number of my containers.

Cheers,
-- 
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
                  C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20140915/fab88116/attachment-0001.asc>