Brock Pytlik wrote:
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?
Currently the installed files reside under /var/pkg/pkg/<stem>/<fmri>/.
Is there a better reason to store them under /var/pkg/pkg/<stem>/?
The advantage of installing them under the fmri is the ease of checking
for the installed file for a particular package version.
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.
'user_installed' is fine, I still prefer explicit/implicit/unknown
since, as I said before, it we decide to have other 'types' later, we
can do so easily without a format change.
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.
My particular concern is that packages might abuse this control to alter
how the packaging system decides to install/uninstall packages.
Encoding it in the packaging format also greatly reduces our ability to
change user intent later in a significant way if we decide to.
I'd rather see something like 'install --intent=deps-explicit' or some
such thing.
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.
The only problem I see with 'recommended' is that possible amount of
overlap between it and 'optional' (which we already have today). It
seems like we could accomplish the same thing you want to do with
recommended by just setting pursue-optional=True by default and applying
the "don't install if uninstalled in the past" logic you mentioned.
However, I agree that there may be some benefit to having "recommended",
but maybe a better name or clarification would be helpful.
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.
If we give the user explicit control over it, as I proposed above, then
we don't need to coordinate anything as they can simply just use the
options to install as appropriate. I think that's preferable over the
headache of coordination.
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.
log_pkg_operation is simply recording something like in the history:
<packages>
<package fmri="<fmri>" old_version="<version>" new_version="<version>"/>
...
</packages>
In short, all of the intent information you're manually recording is
fine to reflect 'current state', but I think all of it needs to be
recorded in history as well to provide a log of user actions.
What you've mentioned for intent, for the most part, is spot on in my
view. However, I think we're also missing the 'version' piece of things.
For example, one aspect of intent I didn't see covered here is whether
the user requested a specific version or requested the stem. In other
words:
pkg install foo
vs.:
pkg install [email protected]
Whether we actually leverage that informational initially doesn't
matter, but I think it's important to record.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
