Am Montag, den 14.04.2014, 14:22 +0200 schrieb Michael Stapelberg: > Hi coldtobi, > > coldtobi <t...@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
signature.asc
Description: This is a digitally signed message part
