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,
entropy@world.std.com
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: