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
