Brock Pytlik wrote:
Shawn Walker wrote:
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.
Right, I'm not changing. I'm making a new file called intent. It's
stored at the stem level because intent is information for a package,
not for a package version. Storing it under the fmri level would just
create migration and consistency headaches.
Ah, ok. You mentioned the 'uninstalled' file earlier, so ...
If you're just adding 'intent' files, then I'm less concerned about the
client versions issue, although we will have to recover gracefully from
older clients manipulating a newer client's image without image versioning.
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.
Well, if you're installing a package from someone, you've already
trusted them not to deliver you malware. I'm curious how a packager
could abuse this control in a way that would be seriously detrimental to
users. At worst (depending on the implementation of group packages which
isn't this proposal), it would leave packages on their system they might
not want.
Abuse/misunderstand, take your pick. I just don't think it's a decision
that a package creator should have to make, or should make.
When the system is making decisions to remove packages, I don't want
that to be done in an unexpected way for the user because the package
creator didn't specify something correctly.
Could you expand on how it would reduce our ability to change it later?
The point is that we don't know how it might change, or be used later
during operations, and I don't feel that we have a clear picture of the
intersection of package creators controlling this behaviour, the
automatic aspects, and whatever user-controllable parts there are.
As the behaviour surrounding this evolves over time, that would mean
that the behaviour originally expected by the package creator would no
longer happen even though the package itself had not changed.
It has to be in the packaging anyway to handle the split package case
(to remove the auto intent propagation).
I'm not certain I agree. It seems like in the split case we'd have all
the information we need to determine what to do automatically.
The problem with a command line flag is that either it likely won't do
what a user wants (tag all dependencies, including libraries) with
intent or will be a cumbersome command line (listing exactly which
dependencies they want marked). Further, I'd argue that it's rare that a
user would think of, or want to, use this. A user shouldn't have to
think about the dependencies of a package, that's the packagers job.
It seems contradictory to me to give users control over the intent in
one part of this proposal, and then decide they shouldn't have it in
another. What difference does it make?
To me the huge benefit of being able to control this now to avoid the
coordination issues outweighs possible cumbersomeness if done right.
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.
I think for now that should live in history. If it needs to be recorded
for some reason, I think that should live in the installed file in
/var/pkg/pkg/state/fmri/installed, since it could vary version by
version. Again, I want to make clear limits on this proposal to prevent
it from blowing up in size. It's to track per-package user intent
regarding install and uninstall for the purposes of improving pkg's UI.
If you can offer an example of a near term consumer (in that framework)
of this information, I'll think more carefully about whether this should
fall within this proposal or not.
I think knowing that a user requested a specific version is useful when
determining when and how to upgrade a package later. This seems like
information that is easy to start recording now, and we can determine
how to use it later. As you already said, it is fairly important that
we just start recording this information so that we can figure out what
to do with it and how to apply it.
The alternative to this proposal would be to have history unpurgeable
from a data storage approach. Simply store every action, and purge
simply effects what's displayed to the user at the command line. Any
information in /var/pkg/pkg/<stem>/intent,
/var/pkg/pkg/<stem>/<fmri>/install, /var/pkg/state/installed/, etc...
would simply be a convenient cache of the data stored in the history file.
History is intended to be purgeable, not only because some users
eventually won't care about a certain period of time, but because of the
LiveCD case, et al.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
