Re: Should ucf be of priority required?
Magnus Holmgren holmg...@debian.org writes: On måndagen den 7 december 2009, Wouter Verhelst wrote: On Sun, Dec 06, 2009 at 01:17:30PM +0100, Patrick Schoenfeld wrote: But how do you fix a package to do what its supposed to do, when it isn't installed anymore? You don't need to. When the package is purged, and ucf doesn't exist anymore, what you do is rm -f the relevant files. Unregistering those files in ucf is necessary so that ucf throws away the correct checksums from its database, too. However, if ucf itself is no longer on the system, then the same is true for that database, and unregistering stuff from that database is no longer necessary. Unless ucf is removed but not purged, right? Shouldn't the question rather be: When will ucf be merged into dpkg? I find is stupid that ucf handled configuration files will not be tracked by dpkg and that dpkg and ucf both implement a keep/replace/merge/diff/whatever interface for updates. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Wed, Jan 20, 2010 at 05:13:21PM +0100, Goswin von Brederlow wrote: Unless ucf is removed but not purged, right? Shouldn't the question rather be: When will ucf be merged into dpkg? I find is stupid that ucf handled configuration files will not be tracked by dpkg and that dpkg and ucf both implement a keep/replace/merge/diff/whatever interface for updates. See http://wiki.debian.org/Teams/Dpkg/RoadMap . Its already on the roadmap. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On måndagen den 7 december 2009, Wouter Verhelst wrote: On Sun, Dec 06, 2009 at 01:17:30PM +0100, Patrick Schoenfeld wrote: But how do you fix a package to do what its supposed to do, when it isn't installed anymore? You don't need to. When the package is purged, and ucf doesn't exist anymore, what you do is rm -f the relevant files. Unregistering those files in ucf is necessary so that ucf throws away the correct checksums from its database, too. However, if ucf itself is no longer on the system, then the same is true for that database, and unregistering stuff from that database is no longer necessary. Unless ucf is removed but not purged, right? -- Magnus Holmgrenholmg...@debian.org Debian Developer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sun, Jan 03 2010, Magnus Holmgren wrote: On måndagen den 7 december 2009, Wouter Verhelst wrote: On Sun, Dec 06, 2009 at 01:17:30PM +0100, Patrick Schoenfeld wrote: But how do you fix a package to do what its supposed to do, when it isn't installed anymore? You don't need to. When the package is purged, and ucf doesn't exist anymore, what you do is rm -f the relevant files. Unregistering those files in ucf is necessary so that ucf throws away the correct checksums from its database, too. However, if ucf itself is no longer on the system, then the same is true for that database, and unregistering stuff from that database is no longer necessary. Unless ucf is removed but not purged, right? Not really. If ucf is removed, then it's database can no longer be trusted to be accurate anyway. So the fact that the removal of the package is not registered in ucf's database makes no difference really (an untrusted DB expected to be out of date is now known to meet expectations). manoj -- Even more amazing was the realization that God has Internet access. I wonder if He has a full newsfeed? (By Matt Welsh) Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
Manoj Srivastava sriva...@debian.org wrote in message news:87my1uhtb7@anzu.internal.golden-gryphon.com... On Mon, Dec 07 2009, Joe Smith wrote: The net result here is that ucf may be keeping excess state related to package foo. But it is not. ucf knows well that when it is reinstalled the state information can't be trusted, it is merely historical, and takes steps to preserve, but not trust, that data. It certainly sounds like a plausible way to leak disk space. And again, ucf has a limit on the historical data that it keeps. Next? If this is the case (and considering that ucf is your software, I'm sure it is), then I see no reason for any changes. UCF does the right thing, and its data stores clearly belong to UCF, and no other packages have any claim to them, nor has any level of responsibility beyond notifying ucf on purge if ucf is still around. So Patrick is worried about nothing, as far as I can tell. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
Hi Manoj, On Mon, Dec 07, 2009 at 12:12:36PM -0600, Manoj Srivastava wrote: For me this assumes that data created during this task belongs to the package that requested the creation of the data in the first place. That breaks abstraction and encapsulation. I'm not sure if I share that view point. The point is to provide a certain interface to a different application to store and access data whereas the using application does not have to take care of the internal structures and consistency of the data. That doesn't mean that the data in question (generally) generally becomes a part that belongs to the interface provider. Consider a database for example. It is encapsulated in the sense, that its only public interface is a query language. But anyways the data stored in the database does not belong to the database. Or would you say it does? But still, you have a right point, in the matter that the database could say that a DROP-operation only removes the data from the working set, not from the history. For example if this is required for consistency reasons. I know that this comparison has its flaws, because in the ucf case the data in question is just a file registration and therefore more a state information as data. BUT according to the manpage not purging the data from the ucf database has practical effects for the package, so its of high interest for the database that the purge operation happened. And it includes providing an interface that does exactly what is it told to do. Sorry. This is not the software paradigm you are looking for. In keeping with modular (and object oriented) design, ucf provides certain facilities. It keeps internal state, but that is opaque to the user. Hm, yeah, probably you are (partly) right. ucf should be able to do what it wants to do, as long as the promise of the interface is kept. That means for ucf purge to remove the registered config file from the working set, but if ucf wants to keep a history file containing the information about that file it can do that. For you the data belongs to ucf and it can do with it whatever it wants to do. So if a postrm requested to purge the file from the database it would also be okay, if ucf didn't do that. Nope. No other package gets to muck around with the internal structures and data for any utility, and that includes files hidden from the application. The API is provided for a purpose: use it, and do not break encapsulation by delving into internal details of the implementation. Actually I consider that I argumented the wrong way, because I described my problem by an effect and not the right one. You are right that the internal details of how ucf stores the data are its own beer. But the original question had nothing to do with that, although this might have been implied. That leads to the point where I have to ask you about something in the manpage. Lets say I'd do the following: - Install a package that uses ucf - Remove the package - Remove ucf - Purge the package using ucf - Re-install the purged package (and therefore pull ucf in again) What would happen? The manpage says that running ucf purge in the postrm *is required* because otherwise a new installation wouldn't work properly (no action is taken). That would mean that in this case something would go wrong. Now I had a quick look at your maintainer scripts and noticed that you divert the old data away on installation. Would that mean that whats beeing said in the manpage is not true in the above stated case, because ucf starts with a new registry anyway? Apart from this: If you always start with a new registry on installation how does that play together with packages that are removed, but not purged and reinstalled later on? E.g. they wouldn't be registered anymore although their modified configuration is still laying around? I won't go further trying to change what I think is wrong. You as the ucf maintainer decided that collecting garbage is okay, because its not garbage in your opinion. Most other people agreed to that or didn't comment at all (including those persons who agree with me). It doesn't matter anyway. Its been a corner case from the beginning, a seldom one additionally. There is work on-going or at least planned to merge ucf functionality into dpkg, which is the better solution IMHO anyway and will probably fix my problem. I was not aware that dpkg was going to expand and work with non conffiles: most of the work is for providing ucf-like handling of conffiles, not for configuration files, unless I am misreading something. The dpkg roadmap [1] has a point Extend conffile support, merge back ucf, which is probably exactly that. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Wed, Dec 09 2009, Patrick Schoenfeld wrote: Hi Manoj, On Mon, Dec 07, 2009 at 12:12:36PM -0600, Manoj Srivastava wrote: For me this assumes that data created during this task belongs to the package that requested the creation of the data in the first place. That breaks abstraction and encapsulation. I'm not sure if I share that view point. The point is to provide a certain interface to a different application to store and access data whereas the using application does not have to take care of the internal structures and consistency of the data. That would be fine if ucf did that: but it does not. You should not look at ucf as something that provides an application an interface to store stuff without having to worry about structure and consistency. It his here to help your package ask questions about whether or not the end user wants to use you configuration file, or theirs, or something else. That doesn't mean that the data in question (generally) generally becomes a part that belongs to the interface provider. Consider a database for example. It is encapsulated in the sense, that its only public interface is a query language. But anyways the data stored in the database does not belong to the database. Or would you say it does? But still, you have a right point, in the matter that the database could say that a DROP-operation only removes the data from the working set, not from the history. For example if this is required for consistency reasons. I know that this comparison has its flaws, because in the ucf case the data in question is just a file registration and therefore more a state information as data. The comparison is false because you start with a wrong premise: that ucf is here to help your app store data in the first place. The data storage is incidental to the primary operation, asking the user questions. And the data is a cache: all it does is help optimize away questions that need not be asked based on the enteries in the registry. You can blow away the registry and still only pay the penalty of ucf asking the user once again what they want to do with a configuration file. BUT according to the manpage not purging the data from the ucf database has practical effects for the package, so its of high interest for the database that the purge operation happened. Yes, and the man page says how you should do the purge *assuming that ucfr is on the system*. If it is not, don't bother. The common case usage is not when you decide to dump ucf before the purge, in which case it is no longer so important since when you remove ucf you render all data collected so far as untrustworthy. That leads to the point where I have to ask you about something in the manpage. Lets say I'd do the following: - Install a package that uses ucf - Remove the package - Remove ucf - Purge the package using ucf - Re-install the purged package (and therefore pull ucf in again) What would happen? The manpage says that running ucf purge in the postrm *is required* because otherwise a new installation wouldn't work properly (no action is taken). That would mean that in this case something would go wrong. Now I had a quick look at your maintainer scripts and noticed that you divert the old data away on installation. Would that mean that whats beeing said in the manpage is not true in the above stated case, because ucf starts with a new registry anyway? Right. The man page does not mention every corner case, but the software still does the right thing. Apart from this: If you always start with a new registry on installation how does that play together with packages that are removed, but not purged and reinstalled later on? E.g. they wouldn't be registered anymore although their modified configuration is still laying around? Sure. And the worst case effect is that the user is asked a question on next update. All the registry does is to optimize away some questions the users have been asked before. If the user removes and re-installs ucf, they get to answer the questions again. That's what you get for dumping a precious, cute, and useful package like ucf, only to realize the error of your ways and have to reinstall it 'cause you can't live without it. manoj -- I develop for Linux for a living, I used to develop for DOS. Going from DOS to Linux is like trading a glider for an F117. -- Lawrence Foard, entr...@world.std.com Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sun, 06 Dec 2009, Steve Langasek wrote: I think there's ongoing work to support debconf prompting for conffiles, but I don't think there's movement on integrating ucf functionality into dpkg. ICBW, though. I don't expect progress soon but it's on dpkg's roadmap: http://wiki.debian.org/Teams/Dpkg/RoadMap So one day ucf might be deprecated by dpkg itself. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
hiya, On Sun, Dec 06, 2009 at 07:36:18PM -0800, Steve Langasek wrote: I think there's ongoing work to support debconf prompting for conffiles, but I don't think there's movement on integrating ucf functionality into dpkg. ICBW, though. there was some work at some point on integrating debconf into dpkg but i don't think anyone's worked on pushing it in a long time. however, there is stuff in the pipes for basic ucf-like functionality[1]. sean [1] tracking of dist versions of conffiles and merging, not dynamic registration though. signature.asc Description: Digital signature
Re: Should ucf be of priority required?
On Sun, Dec 06, 2009 at 11:47:11PM -0600, Manoj Srivastava wrote: In this particular case, what is the harm befalling the user? Well, I don't think that making an Operating System is just about keeping harm away from our users. But it is a tenet of software design that to change something that is working, you have to have some justification beyond I wish things were different. Making the software better, in this case. But this is quiet abstract in this case, because this is not changing the design of a specific tool, its about making the tool *always* perform its duties. I, on the other hand, _know_ you are not getting it. Oh, fine. Leads us to a new level on our discussion. All I'm talking about is: The package that is beeing purged created data during its installation. If it is beeing purged, it should remove this data unless there is a good reason to keep it. No it did not. The data is all internal to ucf, the package has no idea what the data is -- and ucf can change it internally in any way it wants, and the package will not be able to do anything about it. You see, this is called, CS, abstraction. The package calls ucf, and sends it a message. ucf does something about it. Right. Which is a perfectly fine form of abstraction. In this case there is not even almost a reason to keep the data. The package that calls ucf does not get to decide this. No, thats wrong. The package that calls ucf does already decide this, in the moment it gets purged and calls out to ucf to let it remove this data, because its not used anymore. The usual case if ucf is installed. It has no use on a fresh installation of the package (and in fact it must not, because the package has been purged). It has no use without reinstalling the package (contrary to logfiles for example). Basically its garbage. Not your call to make. Well, its a fact. ucf does not need this data, the package does not need that data. Not even the administrator needs that data. If ucf does something wrong with it, point it out, and file a bug. I never said that ucf does something wrong. I said that it does not have the chance to do its duties. So under this aspect I do not see how you can argue that I would need to make a case why this should not happen. Shouldn't it be the other way round? Shouldn't we make a case why we should or can leave *garbage* on the users system when *purging* the package who created that garbage? Internal state information of icf is not garbage. It is not Right. Its not garbage as long as it is a state information. It isn't anymore when the package which created it, is purged, because there is nothing ucf has to act on anymore. Just to rememember: purge The package is selected to be purged (i.e. we want to remove everything, even configuration files). Bingo. These files do not belong to the package. They belong to ucf. Why is that so hard to understand? Ah, so we get to the point that you've never spoken out but wanted to make me understand. Now I know, why you think that you know that I haven't gotten it. Well, in this point we simply disagree. The data in question is not needed by ucf at this point. In fact ucf would never have needed this data, if the package wasn't installed in the first place. And even since it has been installed the data has more relevance to the package itself, because ucf is just a tool to aid the maintainer scripts in getting a job done. And the fact that purging a package, which uses ucf, usually would remove the data from the ucf registry as well weakens your point. If it would belong to ucf why bother with removing it at all? I think you are very mistaken. I could say the same from you. Thats how it is, if opinions differ. But I come to the conclusion that its not worth discussing it anymore. Its a minimal issue and we will not reach a consense. Other people are not involved in the discussion anymore, so EOD for me. Regards, Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Mon, Dec 07, 2009 at 09:08:08AM +0100, Raphael Hertzog wrote: So one day ucf might be deprecated by dpkg itself. That day will be a good day. Thanks for the news. Regards, Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sun, Dec 06, 2009 at 01:17:30PM +0100, Patrick Schoenfeld wrote: On Sat, Dec 05, 2009 at 12:39:28PM -0800, Steve Langasek wrote: There's no reason that ucf *should* fall under either of these rules; so even if ucf /didn't/ work the way it does, the right solution here would be to fix it so that it did, not to add it to Essential. Makes sense. But how do you fix a package to do what its supposed to do, when it isn't installed anymore? You don't need to. When the package is purged, and ucf doesn't exist anymore, what you do is rm -f the relevant files. Unregistering those files in ucf is necessary so that ucf throws away the correct checksums from its database, too. However, if ucf itself is no longer on the system, then the same is true for that database, and unregistering stuff from that database is no longer necessary. That does require an appropriate else clause in postrm files that use ucf, and you should probably file bugs against those that don't, but that's about it. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Mon, Dec 07 2009, Patrick Schoenfeld wrote: On Sun, Dec 06, 2009 at 11:47:11PM -0600, Manoj Srivastava wrote: In this particular case, what is the harm befalling the user? Well, I don't think that making an Operating System is just about keeping harm away from our users. But it is a tenet of software design that to change something that is working, you have to have some justification beyond I wish things were different. Making the software better, in this case. Again, you make an assertion, without any basis for it. Why is it better, apart from the fact you seem to think it would be? What use case is being negatively impacted? But this is quiet abstract in this case, because this is not changing the design of a specific tool, its about making the tool *always* perform its duties. The tool is always performing its duties, really. What it needs to do depends on state, and the environment, which you don't take into account. In this case there is not even almost a reason to keep the data. The package that calls ucf does not get to decide this. No, thats wrong. The package that calls ucf does already decide this, in the moment it gets purged and calls out to ucf to let it remove this data, because its not used anymore. The usual case if ucf is installed. No. It does not decide what ucf does. It does not decide that ucf actually does anything; or puts it into a RDBMS, or into a file, or ignores it. All it does is to make a call to ucf. ucf decides how to handle the call, or whether even to offer the interface. Well, its a fact. ucf does not need this data, the package does not need that data. Not even the administrator needs that data. True. But when the internal staate information is discarded depends on ucf. It can keep the data around for historical reasons if it wants. If ucf does something wrong with it, point it out, and file a bug. I never said that ucf does something wrong. I said that it does not have the chance to do its duties. And I say it does do its duties. Point me to what duties are failed as far as its use case actors are concerned (don't talk to me about internal details of the abstraction, which are none of your business). Well, in this point we simply disagree. The data in question is not needed by ucf at this point. In fact ucf would never have needed this data, if the package wasn't installed in the first place. And even since it has been installed the data has more relevance to the package itself, because ucf is just a tool to aid the maintainer scripts in getting a job done. And ucf gets to decide what it does with its internal state information. It can keep data no longer needed if it wants, for historical purposes (and tomorrow, provide a log of activities -- not that I am promising to code that). Stay the hell out of the internal details of the service, and how it provides the functionality beneath it's API. And the fact that purging a package, which uses ucf, usually would remove the data from the ucf registry as well weakens your point. If it would belong to ucf why bother with removing it at all? usually, ucf would be in a different part of its internal state diagram, and its behaviour would be different. ucf gets to decide how it behaves in different internal states with respect to internal state data. manoj -- The system was down for backups from 5am to 10am last Saturday. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
Hi, (uhm.. I really hate it, if I can't hold the promises to myself I made; in this case: not further discussing it, but still here is another answer) On Mon, Dec 07, 2009 at 10:04:14AM -0600, Manoj Srivastava wrote: On Mon, Dec 07 2009, Patrick Schoenfeld wrote: On Sun, Dec 06, 2009 at 11:47:11PM -0600, Manoj Srivastava wrote: In this particular case, what is the harm befalling the user? Well, I don't think that making an Operating System is just about keeping harm away from our users. But it is a tenet of software design that to change something that is working, you have to have some justification beyond I wish things were different. Making the software better, in this case. Again, you make an assertion, without any basis for it. Why is it better, apart from the fact you seem to think it would be? What use case is being negatively impacted? Yes, I do make an assertion. But not without any basis. Its just not a basis that you accept. All boils down to the points where we disagree the most: - I consider data that is used *nowhere* as garbage. You think its not garbage, because you could use it some time in the future. - I consider ucf just a tool doing a certain duty on behalf of the package requesting it. For me this assumes that data created during this task belongs to the package that requested the creation of the data in the first place. And it includes providing an interface that does exactly what is it told to do. For you the data belongs to ucf and it can do with it whatever it wants to do. So if a postrm requested to purge the file from the database it would also be okay, if ucf didn't do that. Apart from this you made clear that you don't want to discuss your software design, because its not my business. Good to know. I won't go further trying to change what I think is wrong. You as the ucf maintainer decided that collecting garbage is okay, because its not garbage in your opinion. Most other people agreed to that or didn't comment at all (including those persons who agree with me). It doesn't matter anyway. Its been a corner case from the beginning, a seldom one additionally. There is work on-going or at least planned to merge ucf functionality into dpkg, which is the better solution IMHO anyway and will probably fix my problem. You won't change my mind. I will not change your mind. So to save us from discussing the topic to death, let us just agree to disagree, ok? Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Mon, Dec 07 2009, Patrick Schoenfeld wrote: Hi, (uhm.. I really hate it, if I can't hold the promises to myself I made; in this case: not further discussing it, but still here is another answer) On Mon, Dec 07, 2009 at 10:04:14AM -0600, Manoj Srivastava wrote: On Mon, Dec 07 2009, Patrick Schoenfeld wrote: On Sun, Dec 06, 2009 at 11:47:11PM -0600, Manoj Srivastava wrote: In this particular case, what is the harm befalling the user? Well, I don't think that making an Operating System is just about keeping harm away from our users. But it is a tenet of software design that to change something that is working, you have to have some justification beyond I wish things were different. Making the software better, in this case. Again, you make an assertion, without any basis for it. Why is it better, apart from the fact you seem to think it would be? What use case is being negatively impacted? Yes, I do make an assertion. But not without any basis. Its just not a basis that you accept. All boils down to the points where we disagree the most: - I consider data that is used *nowhere* as garbage. You think its not garbage, because you could use it some time in the future. Right. - I consider ucf just a tool doing a certain duty on behalf of the package requesting it. Yup. The task is to ask the user about how they want to handle what is done to files when the package is being upgraded. For me this assumes that data created during this task belongs to the package that requested the creation of the data in the first place. That breaks abstraction and encapsulation. And it includes providing an interface that does exactly what is it told to do. Sorry. This is not the software paradigm you are looking for. In keeping with modular (and object oriented) design, ucf provides certain facilities. It keeps internal state, but that is opaque to the user. For you the data belongs to ucf and it can do with it whatever it wants to do. So if a postrm requested to purge the file from the database it would also be okay, if ucf didn't do that. Nope. No other package gets to muck around with the internal structures and data for any utility, and that includes files hidden from the application. The API is provided for a purpose: use it, and do not break encapsulation by delving into internal details of the implementation. Apart from this you made clear that you don't want to discuss your software design, because its not my business. Good to know. No, I meant it is not the business of any application that uses the interfaces that ucf provides. I'll be happy to discuss the design. I'll be even happier to support any use cases you can bring up and advocate. I won't go further trying to change what I think is wrong. You as the ucf maintainer decided that collecting garbage is okay, because its not garbage in your opinion. Most other people agreed to that or didn't comment at all (including those persons who agree with me). It doesn't matter anyway. Its been a corner case from the beginning, a seldom one additionally. There is work on-going or at least planned to merge ucf functionality into dpkg, which is the better solution IMHO anyway and will probably fix my problem. I was not aware that dpkg was going to expand and work with non conffiles: most of the work is for providing ucf-like handling of conffiles, not for configuration files, unless I am misreading something. You won't change my mind. I will not change your mind. So to save us from discussing the topic to death, let us just agree to disagree, ok? That's a cop out. It is, as you said, my package, and I will listen to people pointing out what are flaws, but I reserve the right to also say why it is not a flaw. As I see it, internal state of a utility is its own, and the very reason it provides an API is to abstract the functionality (so internal implementation can change), encapsulate internal state and data (so other applications and users don't have to worry about how things are implemented). If any supported use cases are broken, that would be a bug. I do not see there is indeed a bug. manoj -- The hearing ear is always found close to the speaking tongue, a custom whereof the memory of man runneth not howsomever to the contrary, nohow. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
I suspect Patrick might be worried about a scenario like the following. Lets assume there is a package Foo that depends on and uses ucf. Further the package is the only one ucing UCF on the system. At some point the admin decides to remove Foo. Since there are no other packages that use ucf on this hypothetical system, the admin also chooses to remove ucf. The admin purges Foo, but not ucf. Later the user installs some other package that uses ucf. The net result here is that ucf may be keeping excess state related to package foo. Since it was not around to be alerted when Foo was purged, ucf is unaware that this excess data may no longer needed. Thus any state of ucf related to the package Foo will live on until some point when ucf is purged, or perhaps if Foo is reinstalled, and then re-removed and re-purged. On the other hand, had the admin purged ucf at the same time that he purged Foo, when ucf was reinstalled later it would start from a clean slate and not keep around this old state that is not terribly useful anymore. Now I'm not familar enough with ucf to know if this is a real possibility. Perhaps ucf's design has something to prevent such a thing from occuring. I'm not sure. It certainly sounds like a plausible way to leak disk space. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Mon, Dec 07 2009, Joe Smith wrote: I suspect Patrick might be worried about a scenario like the following. Lets assume there is a package Foo that depends on and uses ucf. Further the package is the only one ucing UCF on the system. At some point the admin decides to remove Foo. Since there are no other packages that use ucf on this hypothetical system, the admin also chooses to remove ucf. The admin purges Foo, but not ucf. Later the user installs some other package that uses ucf. The net result here is that ucf may be keeping excess state related to package foo. But it is not. ucf knows well that when it is reinstalled the state information can't be trusted, it is merely historical, and takes steps to preserve, but not trust, that data. Since it was not around to be alerted when Foo was purged, ucf is unaware that this excess data may no longer needed. Thus any state of ucf related to the package Foo will live on until some point when ucf is purged, or perhaps if Foo is reinstalled, and then re-removed and re-purged. That would have been very bad design, and a bug. On the other hand, had the admin purged ucf at the same time that he purged Foo, when ucf was reinstalled later it would start from a clean slate and not keep around this old state that is not terribly useful anymore. And lose all historical data about the state of the system. I prefer to not throw away information when it can reasonably be kept. Now I'm not familar enough with ucf to know if this is a real possibility. Perhaps ucf's design has something to prevent such a thing from occuring. It is not a possibility. I'm not sure. Then perhaps asking, rather than insisting on breaking encapsulation, should be the first thing to try to do? Either read the code, or ask first? It certainly sounds like a plausible way to leak disk space. And again, ucf has a limit on the historical data that it keeps. Next? manoj not really a novice in software design anymore. -- Pudder's Law: Anything that begins well will end badly. (Note: The converse of Pudder's law is not true.) Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On So, 06 Dez 2009, Manoj Srivastava wrote:
So, policy does not require dependencies to be around at least
during purge.
Ah yes of course, sorry. I was referring to the remove phase, where it
is also not present, although policy states it.
Best wishes
Norbert
Norbert Preiningprein...@{jaist.ac.jp, logic.at, debian.org}
JAIST, JapanTU Wien, Austria Debian TeX Task Force
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
GLORORUM (n.)
One who takes pleasure in informing others about their bowel
movements.
--- Douglas Adams, The Meaning of Liff
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sat, Dec 05, 2009 at 11:44:39AM -0600, Manoj Srivastava wrote: Making a package essential in order to avoid a if clause in postinsts is very likely too frivolous a reason to pass muster, yes. I do not want to avoid the if-clause. I want to avoid leaving modified files around when removing a package, that modified them (indirectly) in the first place. Regards, Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sat, Dec 05, 2009 at 12:39:28PM -0800, Steve Langasek wrote: There's no reason that ucf *should* fall under either of these rules; so even if ucf /didn't/ work the way it does, the right solution here would be to fix it so that it did, not to add it to Essential. Makes sense. But how do you fix a package to do what its supposed to do, when it isn't installed anymore? This is a corner-case and I wonder weither we should handle it and how we should handle it. Making ucf is essential is one idea, getting the functionality merged back into an utility which is already essential would be another. Regards, Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
Hello, On Sat, Dec 05, 2009 at 08:35:38PM -0600, Manoj Srivastava wrote: I never said that. The problem are not the files owned by the package, but the files owned by ucf, which are modified by ucfr, while not restoring the changes if ucf is not around. Well, if ucf is not around, one should not expect the internal state of ucf to be up to date. Is this a problem? depends on what you expect. I would expect or no lets say I wish that purging a package removes all traces that the package where installed in the first place, except the cases where this is inappropriate (for example: there is a good reason not to remove logfiles on purge). Basically this is a very common assumption for using a package management at all, I think. Yep. This is the whole point of asking this: Is this a problem for us or do we simply ignore it? E.g. the fact that a package can change the state of an external program, but eventually not restore it. The problem with it that the change is bound to the package removed, not to ucf, thats why I'm wondering at all. That's pretty abstract. And this generally, there might not be something one may say one way or the other, and have to deal with it on a case by case basis. Is it? The case with ucf and $random_package is a concrete example of leaving modified files around when purging a package that is associated to the change. For no good reason, except technical inability. In this particular case, do you see I concrete problem that I do not? If you think there is a concrete problem, can you explain? I can't see a problem here, and the ucf man page has wat I beliece to be the correct advice. again, depends on what you expect. Reinstalling the package will not cause any harm when the package is in the ucf registry, will it? So, it doesn't have any practical effect (tough luck!), except that there are still modified files around, when you purge the package and ucf is not around. Considering other cases we are not yet aware of, would be abstract, but I don't think this is. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
Hi, On Sat, Dec 05, 2009 at 11:43:28AM -0600, Manoj Srivastava wrote: This is where things break down. ucf --purge does not do what you think it does, it by no means removes the configuration files. You remove the configuration files, not ucf. It seems that I expressed myself unclear, because several people (like you) read from my sentences that I expect ucf to remove the configuration files. This is not the case. I perfectly understand what ucf --purge does. Actually the point is what a random package should do if it is beeing purged in order to undo what it has done on installation in the corner-case when ucf is beeing removed. Regards, Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sun, Dec 06, 2009 at 06:12:24AM +0100, Norbert Preining wrote: Not wanting to start another flame war, but ... On Sa, 05 Dez 2009, Patrick Schoenfeld wrote: The crux is the last point. For a good reason postrm must not require tools it depends on to be around when removing the package itself. making dpkg policy compliant would help, too, then we removed package can expect dependcies to be present. Seems like this would be tough work for dpkg to handle ;) Apart from this (Warning: What comes next is not really thought about): Would it be an option to let dpkg support the purge action in its prerm script and run ucf --purge therein? Is this possible at all? Regards, Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sat, 5 Dec 2009 21:48:44 +0100, Michael Banck mba...@debian.org wrote: On Sat, Dec 05, 2009 at 12:39:28PM -0800, Steve Langasek wrote: the right solution here would be to fix it so that it did, not to add it to Essential. On a side note, I thought the right solution was to integrate the ucf functionality into dpkg. Any update on this, or was this just wishful thinking on my part? I would go the contrary way: ditch dpkg conffile handling and have it handled from without dpkg. That way, one has the chance of hooking into the process for local modifications. For example, I have been looking for a way to tamper with package a's dpkg-conffiles from package b, which would be very helpful for local sysadmin work (such as rolling out local configuration via a package). Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sun, Dec 06 2009, Patrick Schoenfeld wrote: Actually the point is what a random package should do if it is beeing purged in order to undo what it has done on installation in the corner-case when ucf is beeing removed. Remove your files, and make a best effort attempt to call other utilities to clean up indirect mods, iff they exist. Which is what is happening here. If you want tohter things to happen, you have to make a case for why (a case that goes beyond I wish it were so). manoj -- To be, or what? Sylvester Stallone Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sun, Dec 06 2009, Patrick Schoenfeld wrote: On Sat, Dec 05, 2009 at 11:44:39AM -0600, Manoj Srivastava wrote: Making a package essential in order to avoid a if clause in postinsts is very likely too frivolous a reason to pass muster, yes. I do not want to avoid the if-clause. I want to avoid leaving modified files around when removing a package, that modified them (indirectly) in the first place. In this particular case, what is the harm befalling the user? What is the use case that will present an actual bad thing happening, apart from your wish that modified files for packages no longer installed but not purged do not remain on the system? manoj -- It's a dog-eat-dog world out there, and I'm wearing Milkbone underwear. Norm, from _Cheers_ Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sun, Dec 06 2009, Norbert Preining wrote: On So, 06 Dez 2009, Manoj Srivastava wrote: So, policy does not require dependencies to be around at least during purge. Ah yes of course, sorry. I was referring to the remove phase, where it is also not present, although policy states it. Are you sure this is the case being discussed? The thread is dealing with ucf -p, which is called when you are purging your package. ,[ Manual page ucf(1) ] | -p, --purge |Removes all vestiges of the file from the state hashfile. This is |required to allow a package to be reinstalled after it is purged; |since otherwise, the real configuration file is removed, but it |remains in the hash file; and on reinstall no action is taken, |since the md5sum of the new file matches that in the hashfile. |In short, remember to use this option in the postrm for every |configuration file managed by ucf when the package is being |purged (assuming ucf itself exists). Note: ucf does not actually |touch the file on disk in this operation, so any file removals |are still the responsibility of the calling package. ` So, I see no indication that dpkg is not following policy, based on this thread. What makes you think it is? manoj -- We are using Linux daily to UP our productivity - so UP yours! (Adapted from Pat Paulsen by Joe Sloan) Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sun, Dec 06 2009, Patrick Schoenfeld wrote: Hello, On Sat, Dec 05, 2009 at 08:35:38PM -0600, Manoj Srivastava wrote: I never said that. The problem are not the files owned by the package, but the files owned by ucf, which are modified by ucfr, while not restoring the changes if ucf is not around. Well, if ucf is not around, one should not expect the internal state of ucf to be up to date. Is this a problem? depends on what you expect. I would expect or no lets say I wish that purging a package removes all traces that the package where installed in the first place, except the cases where this is inappropriate (for example: there is a good reason not to remove logfiles on purge). Basically this is a very common assumption for using a package management at all, I think. You have expressed an opinion, no, a wish, that something happens one way. What you have not demonstrated a concrete harm that happens in this case when your wish is not granted. Yep. This is the whole point of asking this: Is this a problem for us or do we simply ignore it? E.g. the fact that a package can change the state of an external program, but eventually not restore it. The problem with it that the change is bound to the package removed, not to ucf, thats why I'm wondering at all. That's pretty abstract. And this generally, there might not be something one may say one way or the other, and have to deal with it on a case by case basis. Is it? The case with ucf and $random_package is a concrete example of leaving modified files around when purging a package that is associated to the change. For no good reason, except technical inability. What harm comes of it? Youhave already removed ucf at this point. What is the sue case you are presenting that suffers? Saying I wish this not to happen, and thus when it happens, that is the harm is circular logic, not a concrete example. In this particular case, do you see I concrete problem that I do not? If you think there is a concrete problem, can you explain? I can't see a problem here, and the ucf man page has wat I beliece to be the correct advice. again, depends on what you expect. Reinstalling the package will not cause any harm when the package is in the ucf registry, will it? If ucf is not around, it does not make a difference one way or the other. Indeed, without ucf being around, the code to manipulate ucf internal data structures is not around either. Your argument seems to be that if a package called ucf in order to have ucf change its internal state, ucf should be kept around to make changes to the internal state, willy nilly? What would that solve, apart from granting your wish? So, it doesn't have any practical effect (tough luck!), except that there are still modified files around, when you purge the package and ucf is not around. These files belong to ucf. When ucf is purged, those files would be removed too. Considering other cases we are not yet aware of, would be abstract, but I don't think this is. So it is a hypothetical harm, with no concrete examples you can think of. manoj -- Complex system: One with real problems and imaginary profits. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
]] Patrick Schoenfeld Hi, | depends on what you expect. I would expect or no lets say I wish that | purging a package removes all traces that the package where installed | in the first place, except the cases where this is inappropriate (for | example: there is a good reason not to remove logfiles on purge). So you would expect a package to be marked as uninstalled and not purged in the dpkg status file when it's purged? And for packages that does not come from Packages file to be completely dropped? If not, what am I missing? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
2009/12/6 Patrick Schoenfeld schoenf...@debian.org: Actually the point is what a random package should do if it is beeing purged in order to undo what it has done on installation in the corner-case when ucf is beeing removed. Regards, Patrick My opinion If ucf is just removed then any dangaling files from other packages should stay under ucf responsibility. If ucf is purged ucf package should nuke all / any dangaling files which were touched by other packages. Maybe i don't understand something -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sun, Dec 06, 2009 at 05:00:18PM +0100, Tollef Fog Heen wrote: ]] Patrick Schoenfeld Hi, | depends on what you expect. I would expect or no lets say I wish that | purging a package removes all traces that the package where installed | in the first place, except the cases where this is inappropriate (for | example: there is a good reason not to remove logfiles on purge). So you would expect a package to be marked as uninstalled and not purged in the dpkg status file when it's purged? And for packages that does not come from Packages file to be completely dropped? In my statement that you cite I already mentioned that for cases where its inappropiate to remove traces of the package it probably makes sense to draw a line. The dpkg status file probably is such a case. I never talked about this, anyway. Regards, Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sun, Dec 06, 2009 at 09:28:11AM -0600, Manoj Srivastava wrote: On Sun, Dec 06 2009, Patrick Schoenfeld wrote: On Sat, Dec 05, 2009 at 11:44:39AM -0600, Manoj Srivastava wrote: Making a package essential in order to avoid a if clause in postinsts is very likely too frivolous a reason to pass muster, yes. I do not want to avoid the if-clause. I want to avoid leaving modified files around when removing a package, that modified them (indirectly) in the first place. In this particular case, what is the harm befalling the user? Well, I don't think that making an Operating System is just about keeping harm away from our users. What is the use case that will present an actual bad thing happening, apart from your wish that modified files for packages no longer installed but not purged do not remain on the system? Why are you talking about modified files to remain on the system? I'm not sure you've got the point. To make it more clear: - I'm _not_ saying that ucf database has to removed, when its removed but not purged. - I'm not talking about the configuration files of package xyz itself. Its clearly the job of the postrm to remove those files and this can happen properly. - I'm not saying that apart from the configuration files any file needs to be *removed* from the system (your statement your wish... files ... do not remain on the system makes me think you imply that) All I'm talking about is: The package that is beeing purged created data during its installation. If it is beeing purged, it should remove this data unless there is a good reason to keep it. In this case there is not even almost a reason to keep the data. It has no use on a fresh installation of the package (and in fact it must not, because the package has been purged). It has no use without reinstalling the package (contrary to logfiles for example). Basically its garbage. So under this aspect I do not see how you can argue that I would need to make a case why this should not happen. Shouldn't it be the other way round? Shouldn't we make a case why we should or can leave *garbage* on the users system when *purging* the package who created that garbage? Shouldn't we make a case, why its ok to have things in our manpages, such as dpkg(1) which are not true? Just to rememember: purge The package is selected to be purged (i.e. we want to remove everything, even configuration files). Otherwise how would your argumentation be different from saying its okay to leave configuration backup files around when uninstalling? The package did not install/create them, dpkg did it. What harm is it causing to the user? What bad thing would actually happen? Thats obvious not a good line to follow and if we'd do it would be in contrast to how Debian solutions in the past seeked to get near perfection. Regards, Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sat, Dec 05, 2009 at 09:48:44PM +0100, Michael Banck wrote: On Sat, Dec 05, 2009 at 12:39:28PM -0800, Steve Langasek wrote: the right solution here would be to fix it so that it did, not to add it to Essential. On a side note, I thought the right solution was to integrate the ucf functionality into dpkg. Any update on this, or was this just wishful thinking on my part? I think there's ongoing work to support debconf prompting for conffiles, but I don't think there's movement on integrating ucf functionality into dpkg. ICBW, though. Of course, it's fine for this functionality to become Essential: yes by virtue of being the standard dpkg way of doing things. :) Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Should ucf be of priority required?
On Sun, Dec 06, 2009 at 01:17:30PM +0100, Patrick Schoenfeld wrote: On Sat, Dec 05, 2009 at 12:39:28PM -0800, Steve Langasek wrote: There's no reason that ucf *should* fall under either of these rules; so even if ucf /didn't/ work the way it does, the right solution here would be to fix it so that it did, not to add it to Essential. Makes sense. But how do you fix a package to do what its supposed to do, when it isn't installed anymore? You don't; but I don't see any evidence that ucf's behavior isn't already correct. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Should ucf be of priority required?
On Sun, Dec 06 2009, Patrick Schoenfeld wrote: On Sun, Dec 06, 2009 at 09:28:11AM -0600, Manoj Srivastava wrote: On Sun, Dec 06 2009, Patrick Schoenfeld wrote: On Sat, Dec 05, 2009 at 11:44:39AM -0600, Manoj Srivastava wrote: Making a package essential in order to avoid a if clause in postinsts is very likely too frivolous a reason to pass muster, yes. I do not want to avoid the if-clause. I want to avoid leaving modified files around when removing a package, that modified them (indirectly) in the first place. In this particular case, what is the harm befalling the user? Well, I don't think that making an Operating System is just about keeping harm away from our users. But it is a tenet of software design that to change something that is working, you have to have some justification beyond I wish things were different. What is the use case that will present an actual bad thing happening, apart from your wish that modified files for packages no longer installed but not purged do not remain on the system? Why are you talking about modified files to remain on the system? These file belongs to ucf, so they live on while ucf is not purged. I'm not sure you've got the point. I, on the other hand, _know_ you are not getting it. To make it more clear: - I'm _not_ saying that ucf database has to removed, when its removed but not purged. Cool. - I'm not talking about the configuration files of package xyz itself. Its clearly the job of the postrm to remove those files and this can happen properly. Sure. - I'm not saying that apart from the configuration files any file needs to be *removed* from the system (your statement your wish... files ... do not remain on the system makes me think you imply that) OK All I'm talking about is: The package that is beeing purged created data during its installation. If it is beeing purged, it should remove this data unless there is a good reason to keep it. No it did not. The data is all internal to ucf, the package has no idea what the data is -- and ucf can change it internally in any way it wants, and the package will not be able to do anything about it. You see, this is called, CS, abstraction. The package calls ucf, and sends it a message. ucf does something about it. In this case there is not even almost a reason to keep the data. The package that calls ucf does not get to decide this. It has no use on a fresh installation of the package (and in fact it must not, because the package has been purged). It has no use without reinstalling the package (contrary to logfiles for example). Basically its garbage. Not your call to make. If ucf does something wrong with it, point it out, and file a bug. So under this aspect I do not see how you can argue that I would need to make a case why this should not happen. Shouldn't it be the other way round? Shouldn't we make a case why we should or can leave *garbage* on the users system when *purging* the package who created that garbage? Internal state information of icf is not garbage. It is not anyone's business but ucf's. If purging ucf left garbage on the system it would be a bug. This is not. Shouldn't we make a case, why its ok to have things in our manpages, such as dpkg(1) which are not true? Just to rememember: purge The package is selected to be purged (i.e. we want to remove everything, even configuration files). Bingo. These files do not belong to the package. They belong to ucf. Why is that so hard to understand? Otherwise how would your argumentation be different from saying its okay to leave configuration backup files around when uninstalling? Bullshit. If ucf left state files around after purging, youmight have some grounds to say that. The package did not install/create them, dpkg did it. What harm is it causing to the user? What bad thing would actually happen? Thats obvious not a good line to follow and if we'd do it would be in contrast to how Debian solutions in the past seeked to get near perfection. I think you are very mistaken. manoj -- * SynrG notes that the number of configuration questions to answer in sendmail is NON-TRIVIAL -- Seen on #Debian Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Should ucf be of priority required?
Hi, when testing my packages with piuparts I noticed an inability of our package management. Dpkg does not have support for management of dynamically generated configuration files. Therefore some packages now use ucf. The basic usage is somewhat like - Registering config files to ucf on installation - Using it when configuring the package to merge configuration updates and local changes - Unregistering config files to ucf on purge The crux is the last point. For a good reason postrm must not require tools it depends on to be around when removing the package itself. So the call of ucf looks something like that: if which ucf /dev/null; then ucf --purge /etc/foo.conf fi That is okay, as long as ucf is around. But as soon as it isn't the purge of a package is succesful while leaving modified files around. So the effect is that a purge does not remove everything. Do we really want that? Should ucf be 'required' to avoid that? Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sat, Dec 05, 2009 at 04:47:18PM +0100, Patrick Schoenfeld wrote: That is okay, as long as ucf is around. But as soon as it isn't the purge of a package is succesful while leaving modified files around. So the effect is that a purge does not remove everything. Do we really want that? Should ucf be 'required' to avoid that? ucf being priority required is not sufficient. It is still possible to remove such a package (mawk is a good example) and therefore you would still need to execute ucf conditionally. The only way around that is to make ucf essential, and I don't think that's a good idea. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Should ucf be of priority required?
On Sat, Dec 05, 2009 at 04:56:02PM +, brian m. carlson wrote: On Sat, Dec 05, 2009 at 04:47:18PM +0100, Patrick Schoenfeld wrote: That is okay, as long as ucf is around. But as soon as it isn't the purge of a package is succesful while leaving modified files around. So the effect is that a purge does not remove everything. Do we really want that? Should ucf be 'required' to avoid that? ucf being priority required is not sufficient. It is still possible to remove such a package (mawk is a good example) and therefore you would still need to execute ucf conditionally. You are right. My bad. The only way around that is to make ucf essential, and I don't think that's a good idea. What speaks against it? Its basically a mini tool (Installed-Size: 260) and not making it essential leads to the mentioned situations. The only bad thing is, that it depends on a tool which is not essential (debconf) and seems not to be able to render questions without debconf. Or should we simply not care about packages modifying files (via external tools) and not reverting those changes when beeing removed? Regards, Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On 2009-12-05 16:47 +0100, Patrick Schoenfeld wrote: Hi, when testing my packages with piuparts I noticed an inability of our package management. Dpkg does not have support for management of dynamically generated configuration files. Therefore some packages now use ucf. The basic usage is somewhat like - Registering config files to ucf on installation - Using it when configuring the package to merge configuration updates and local changes - Unregistering config files to ucf on purge - Removing config files on purge The crux is the last point. For a good reason postrm must not require tools it depends on to be around when removing the package itself. So the call of ucf looks something like that: if which ucf /dev/null; then ucf --purge /etc/foo.conf fi That is okay, as long as ucf is around. But as soon as it isn't the purge of a package is succesful while leaving modified files around. It is the package's responsibility to remove those files, ucf --purge does not do that, see ucf(1). So the effect is that a purge does not remove everything. Do we really want that? Should ucf be 'required' to avoid that? That would be no good. Sven -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sat, Dec 05 2009, brian m. carlson wrote: On Sat, Dec 05, 2009 at 04:47:18PM +0100, Patrick Schoenfeld wrote: That is okay, as long as ucf is around. But as soon as it isn't the purge of a package is succesful while leaving modified files around. So the effect is that a purge does not remove everything. Do we really want that? Should ucf be 'required' to avoid that? ucf being priority required is not sufficient. It is still possible to remove such a package (mawk is a good example) and therefore you would still need to execute ucf conditionally. The only way around that is to make ucf essential, and I don't think that's a good idea. Making a package essential in order to avoid a if clause in postinsts is very likely too frivolous a reason to pass muster, yes. manoj -- The Constitution may not be perfect, but it's a lot better than what we've got! Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sat, Dec 05 2009, Patrick Schoenfeld wrote: Short Answer: hell no. Read below for why that would be a bad idea. when testing my packages with piuparts I noticed an inability of our package management. Dpkg does not have support for management of dynamically generated configuration files. Therefore some packages now use ucf. The basic usage is somewhat like - Registering config files to ucf on installation - Using it when configuring the package to merge configuration updates and local changes - Unregistering config files to ucf on purge The crux is the last point. For a good reason postrm must not require tools it depends on to be around when removing the package itself. So the call of ucf looks something like that: if which ucf /dev/null; then ucf --purge /etc/foo.conf fi That is okay, as long as ucf is around. And if ucf is not around, why bother cleaning up the ucf cache? When ucf is purged, it will remove its own darned cache. But as soon as it isn't the purge of a package is succesful while leaving modified files around. So the effect is that a purge does not remove everything. This is where things break down. ucf --purge does not do what you think it does, it by no means removes the configuration files. You remove the configuration files, not ucf. Do we really want that? Should ucf be 'required' to avoid that? What purpose would that serve? manoj -- Never try to teach a pig to sing; it wastes your time and it annoys the pig. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
Patrick Schoenfeld wrote: So the call of ucf looks something like that: if which ucf /dev/null; then ucf --purge /etc/foo.conf fi no, the correct one is: if which ucf /dev/null; then $whatever_ucf_command /etc/foo.conf else rm -f /etc/foo.conf fi -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: daniel.baum...@panthera-systems.net Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On 2009-12-05, Daniel Baumann dan...@debian.org wrote: Patrick Schoenfeld wrote: So the call of ucf looks something like that: if which ucf /dev/null; then ucf --purge /etc/foo.conf fi no, the correct one is: if which ucf /dev/null; then $whatever_ucf_command /etc/foo.conf else rm -f /etc/foo.conf fi -p, --purge Removes all vestiges of the file from the state hashfile. [...] Note: ucf does not actually touch the file on disk in this operation, so any file removals are still the responsibility of the calling package. See man ucf. Kind regards, Philipp kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sat, Dec 05, 2009 at 06:17:20PM +0100, Patrick Schoenfeld wrote: ucf being priority required is not sufficient. It is still possible to remove such a package (mawk is a good example) and therefore you would still need to execute ucf conditionally. You are right. My bad. The only way around that is to make ucf essential, and I don't think that's a good idea. What speaks against it? Its basically a mini tool (Installed-Size: 260) and not making it essential leads to the mentioned situations. The only bad thing is, that it depends on a tool which is not essential (debconf) and seems not to be able to render questions without debconf. Or should we simply not care about packages modifying files (via external tools) and not reverting those changes when beeing removed? Aside from the misunderstanding about how ucf works in practice, this doesn't belong as Essential because Essential exists for two reasons: - to resolve dependency loops in the core system that otherwise could not be solved - to declare the minimal set of functionality that must be available and usable on the system at all times, even when not configured There's no reason that ucf *should* fall under either of these rules; so even if ucf /didn't/ work the way it does, the right solution here would be to fix it so that it did, not to add it to Essential. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Should ucf be of priority required?
On Sat, Dec 05, 2009 at 12:39:28PM -0800, Steve Langasek wrote: the right solution here would be to fix it so that it did, not to add it to Essential. On a side note, I thought the right solution was to integrate the ucf functionality into dpkg. Any update on this, or was this just wishful thinking on my part? Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sat, Dec 05 2009, Patrick Schoenfeld wrote: What speaks against it? Its basically a mini tool (Installed-Size: 260) and not making it essential leads to the mentioned situations. I am afraid I do not follow -- what situations are improved by making ucf essential? The only bad thing is, that it depends on a tool which is not essential (debconf) and seems not to be able to render questions without debconf. Actually, the ask questions without debconf functionality was ripped out just a couple of months ago, since not using debconf is now a policy violation. Or should we simply not care about packages modifying files (via external tools) and not reverting those changes when beeing removed? If you are going to remove the file, why bother reverting any changes? manoj -- It is a poor judge who cannot award a prize. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sat, Dec 05, 2009 at 06:37:45PM +0100, Sven Joachim wrote: It is the package's responsibility to remove those files, ucf --purge does not do that, see ucf(1). I never said that. The problem are not the files owned by the package, but the files owned by ucf, which are modified by ucfr, while not restoring the changes if ucf is not around. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sat, Dec 05, 2009 at 07:16:58PM +0100, Daniel Baumann wrote: Patrick Schoenfeld wrote: So the call of ucf looks something like that: if which ucf /dev/null; then ucf --purge /etc/foo.conf fi no, the correct one is: if which ucf /dev/null; then $whatever_ucf_command /etc/foo.conf else rm -f /etc/foo.conf fi You don't get the point. ucf does not remove the files, it removes the files from its own registry. So your if-else doesn't really help. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sat, Dec 05 2009, Patrick Schoenfeld wrote: On Sat, Dec 05, 2009 at 06:37:45PM +0100, Sven Joachim wrote: It is the package's responsibility to remove those files, ucf --purge does not do that, see ucf(1). I never said that. The problem are not the files owned by the package, but the files owned by ucf, which are modified by ucfr, while not restoring the changes if ucf is not around. Well, if ucf is not around, one should not expect the internal state of ucf to be up to date. Is this a problem? manoj -- You can't make a program without broken egos. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sat, Dec 05, 2009 at 05:25:29PM -0600, Manoj Srivastava wrote: On Sat, Dec 05 2009, Patrick Schoenfeld wrote: On Sat, Dec 05, 2009 at 06:37:45PM +0100, Sven Joachim wrote: It is the package's responsibility to remove those files, ucf --purge does not do that, see ucf(1). I never said that. The problem are not the files owned by the package, but the files owned by ucf, which are modified by ucfr, while not restoring the changes if ucf is not around. Well, if ucf is not around, one should not expect the internal state of ucf to be up to date. Is this a problem? Yep. This is the whole point of asking this: Is this a problem for us or do we simply ignore it? E.g. the fact that a package can change the state of an external program, but eventually not restore it. The problem with it is, that the change is bound to the package removed, not to ucf, thats why I'm wondering at all. Regards, Patrick manoj -- You can't make a program without broken egos. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sat, Dec 05 2009, Patrick Schoenfeld wrote: On Sat, Dec 05, 2009 at 05:25:29PM -0600, Manoj Srivastava wrote: On Sat, Dec 05 2009, Patrick Schoenfeld wrote: On Sat, Dec 05, 2009 at 06:37:45PM +0100, Sven Joachim wrote: It is the package's responsibility to remove those files, ucf --purge does not do that, see ucf(1). I never said that. The problem are not the files owned by the package, but the files owned by ucf, which are modified by ucfr, while not restoring the changes if ucf is not around. Well, if ucf is not around, one should not expect the internal state of ucf to be up to date. Is this a problem? Yep. This is the whole point of asking this: Is this a problem for us or do we simply ignore it? E.g. the fact that a package can change the state of an external program, but eventually not restore it. The problem with it that the change is bound to the package removed, not to ucf, thats why I'm wondering at all. That's pretty abstract. And this generally, there might not be something one may say one way or the other, and have to deal with it on a case by case basis. In this particular case, do you see I concrete problem that I do not? If you think there is a concrete problem, can you explain? I can't see a problem here, and the ucf man page has wat I beliece to be the correct advice. manoj -- It is bad luck to be superstitious. Andrew W. Mathis Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
Not wanting to start another flame war, but ...
On Sa, 05 Dez 2009, Patrick Schoenfeld wrote:
The crux is the last point. For a good reason postrm must not require
tools it depends on to be around when removing the package itself.
making dpkg policy compliant would help, too, then we removed package
can expect dependcies to be present.
Best wishes
Norbert
Norbert Preiningprein...@{jaist.ac.jp, logic.at, debian.org}
JAIST, JapanTU Wien, Austria Debian TeX Task Force
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
DULUTH (adj.)
The smell of a taxi out of which people have just got.
--- Douglas Adams, The Meaning of Liff
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should ucf be of priority required?
On Sat, Dec 05 2009, Norbert Preining wrote: Not wanting to start another flame war, but ... On Sa, 05 Dez 2009, Patrick Schoenfeld wrote: The crux is the last point. For a good reason postrm must not require tools it depends on to be around when removing the package itself. making dpkg policy compliant would help, too, then we removed package can expect dependcies to be present. Umm, what parts of policy would that be? ,[ 7.2. Binary Dependencies - `Depends' ... ] | `Depends' | This declares an absolute dependency. A package will not be | configured unless all of the packages listed in its `Depends' | field have been correctly configured. | | The `Depends' field should be used if the depended-on package is | required for the depending package to provide a significant | amount of functionality. | | The `Depends' field should also be used if the `postinst', | `prerm' or `postrm' scripts require the package to be present in | order to run. Note, however, that the `postrm' cannot rely on | any non-essential packages to be present during the `purge' | phase. ` So, policy does not require dependencies to be around at least during purge. manoj -- My only love sprung from my only hate! Too early seen unknown, and known too late! -- William Shakespeare, Romeo and Juliet Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
