Brock Pytlik wrote:
Problem:
Proposal:
We'll make use of the existing structure of var/pkg/state. In addition
to var/pkg/state/installed, var/pkg/state/uninstalled will be created.
The files in these directories, one per package stem, will be augmented
to contain the intent information.
Why use the /var/pkg/state/installed/<fmri> files, instead of these:
/var/pkg/pkg/<stem>/<fmri>/installed
?
Notably, the 'installed' file above already contains the name of the
publisher used to install the package. See below for further comments
on this.
I'm deliberately not making use of history as an already existing store
for one substantial reason, history can be purged. I believe that we
want user intent to be persistent and unable to be purged (or, at least
that purging it should make the consequences very clear) while purging
pkg history appears to be there for a UI need.
Agree.
The on-disk record of intent will be written after the bits have been
successfully written to disk, at the same time the history information
is recorded. As far as I can tell, the information needed is "did the
user explicitly install this package" and "did the user explicitly
choose a publisher." These will be the two bits of information recorded
initially. The data will be stored as key-value pairs, in this case
"user_installed=True/False" and "publisher_chosen=P_<name of
publisher>/None". When asking about user intent, the consumer/client
will either receive a value or a response of "Unknown."
I'd prefer slightly more general naming and flexibility for the attributes:
request=(explicit|implicit)
publisher=(explicit|implicit)
If you take into account that the 'installed' files I mentioned above
already have the publisher contained within, this format is a bit more
flexible. By flexible, I mean that if we need to distinguish between
different types of explicit/implicit in the future, we can, which is
something a boolean won't provide.
It's also likely that we would want to allow a package to specify that
certain dependencies should have install intent propagated. The example
I have at the moment is slim_install. By specifying that the
dependencies on firefox, thunderbird, and the other user facing packages
should have user intent propagated, reasonable defaults will appear on
the installed system.
I'm not certain that we should allow packages to control user intent
behaviour. I'd prefer we find a way to determine how and when to record
that by some other set of criteria automatically.
I'm also not yet keen on the idea of having to coordinate delivery of an
intent file of the LiveCD environment with the install group. Since
they build an image using the distribution constructor, and that uses
pkg(1), won't this information be generated automatically?
I suppose it depends on how they install packages to that image.
Those are my current plans and thoughts. I'd appreciate any comments or
suggestions.
There's some overlap here with the log_pkg_operation() method I
mentioned in the License Action proposal thread:
http://markmail.org/thread/m5mp63hfmd2nq6ys
Perhaps that could be removed from the license action proposal and done
as part of this proposal instead since it is really about tracking part
of user intent?
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
