[Pkg-systemd-maintainers] Bug#619244: Bug#619244: systemd: unowned files after purge (policy 6.8, 10.8): /etc/machine-id

[Tobias Frost]

Am Montag, den 14.04.2014, 14:22 +0200 schrieb Michael Stapelberg:
> Hi coldtobi,
> 
> coldtobi <tobi at coldtobi.de> writes:
> > Maybe new imput:
> > On drizzle I had the same issue with database files.
> > My solution was to ask the user (debconf) if the files should be removed on
> > purge, and defaulted that to yes. This is compliant with the policy and you can
> > still explain why this file is needed and why systemd suggests to keep the
> > file. 
> I don’t think this is a good idea. Users should not be bothered with
> technical details such as this just for following the policy to the word.

Well, I disagree... (Obviously otherwise I wouldn't have proposed it in
the first place). 
First, IMHO purging systemd will not be a task non-techies person will
do often, and the techie person how chooses to switch her init system to
something else will be indeed not be bugged by an debconf question and
be able to judge that technical detail.
Also, as the systemd folks writes [1] that there is no harm if the
system id is gone, because it allows for the exception of stateless
machines. 
So I see no backside, except that some people how know what they are
doing will see that debconf dialog and there they can be still eductated
why it is a bad idea(tm) to remove the machine-id. I actually still
think that would be quite elegant and almost no visibilty to user which
do not care about how systemd ticks.

[1] http://www.freedesktop.org/software/systemd/man/machine-id.html

(Additionally, I do not like the idea of another persitent tracking id
on my machine, and after searching the New I'm know that others share my
feelings; but that's off-topic now.) 

Earlier in this bugreport the idea to have this file also when the user
has no systemd installed was brought up: This theorectically forces
people how do not want to have this id on also to have it.
Somehow also a expectation one could have on Debian is if you purge a
package, everything is removed, leaving no traces. (Beside technical
limitations of course; but this id is no such technical limitation,
IMHO)    

My opinion on the policy is that the text makes sense, has a lots of
experience in it and was written on purpose that way it is. Frankly I
don't see why any package should be  excluded from the rules the policy
set up. (And there is always debian-policy to discuss in case its needed
to be changed/interprated/exceptions needed)


> > BTW, *why* does systemd needs this file to be constant? Google did not have an
> > answer for me... Do you have a pointer? I only found a reference that it can be
> > regenerated on stateless systems, so out of this I assume things will not break
> > if someone purges systemd and later reinstall it.
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619244#45

Maybe my question was poorly formulated: 
While this file describes the machine-id, I cannot read the purpose out
of your link: What are the benefits I (as user) would have from it and
why it would be bad to remove that file on purge ( which is already
quite unlikely, as layed out above). 

> > (Please note that this bug has a huge impact on piuparts testing, as all
> > packages directly and indirectly depending on systemd will not be tested until
> > this is fixed policy-like)
> Then please work on fixing it…? :)

That's why I proposed this solution in the first place. 
I don't see that this is a bug in piuparts, do you?

> I think the best option (as discussed in this bug already) is to move
> the file to a more central package like base-files.

I personally don't like that idea, because it moves files to a package
which has no business with the file: And that somehow feels wrong, not
warranted and not really intuitively  enough to me. Also this somehow
entangles people not wanting systemd-stuff on their system.

-- 
Tobi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20140414/c0d11d79/attachment-0002.sig>