Shawn Walker wrote:
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.
Actually, I was wrong when I proposed this originally. I missed that the
files there contained the full fmri in their name. How would a
/var/pkg/pkg/<stem>/intent file work for you?
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.
Well, none of the values were booleans as proposed. user_installed could
be True, False, or Unknown. I'm happy with the change suggested to make
publisher explicit/implicit. I don't like 'request' as a name as I think
it's not clear what it means. If you prefer explicit/implicit/unknown
for user_installed, that's fine with me, though I think T/F, Yes/No is
clearer.
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 open to suggestions. I gave this a fair bit of thought and ended up
deciding that this was a reasonable power to give to packagers since we
have to give them the ability to not propagate intent in the case of
splitting a package. It's also possible that slim_install is simply a
special case that we should treat as such, but it seemed to me that
there where we've observed one need, others are likely to have a similar
need.
I had another proposal for dealing with slim_install, which is to
introduce a new kind of dependency, perhaps called "recommened." The
idea for those would be that the dependency would be pulled in unless
the user had explicitly uninstalled it in the past. That would mean that
it would no longer be necessary to remove slim_install during install.
However, it wouldn't fix the issue that if a user uninstalled
slim_install, none of the packages it caused to be installed would be
marked as intentionally installed. The true purpose of this change would
be to allow slim_install to remain on the image so that image-updates
would pull down new packages.
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.
See step 5 below. I think coordinating with install is just something
we're going to have to do. I'd like for this to be generated
automatically, but as you noted it depends greatly on exactly how they
install the packages. I haven't investigated this yet, but my guess is
that it's roughly:
pkg install entire
pkg install SUNWcs
(possibly one or two other special pacakges)
pkg install slim_install
Without allowing a package to propagate intent (or special casing
slim_install which seems like a bad idea to me), only entire, SUNWcs,
and slim_install will be marked as intentionally installed. slim_install
also contains all the packages to be installed (I think) or it at least
includes some library packages like SUNWglib2. There are a variety of
ways we can fix things with the installer, however, I don't think it
makes sense to stall this work on coordination with them. I'm plan to
come up with a simple solution that will let the rest of the work
integrate (most likely blowing away all intent info), then we can
revisit things and make things more perfect.
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?
I'll need you to elaborate more on the overlap you're seeing since I
don't have enough context to understand what the log_pkg_operation()
method is going to be recording, and why it's part of the license action
changes. In general, I'd like to keep this as narrow as possible as I've
experienced the joys of wad creep in the past and nothing good comes
from it.
Brock
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
