To summarize what follows:
1) I think package publishers are in a better position to know the
contents and purposes of their packages than the packaging system.
2) Most users don't want to think about their packaging system, it
should Just Work.
3) Thus, packagers need tools to convey their intent to the packaging
system so that the packaging can get things right for most users most of
the time.
4) That tools are available for sophisticated users doesn't obviate the
need for 3.
Shawn Walker wrote:
Brock Pytlik wrote:
[snip]
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.
Of course it is. Who else is in the best position to decide what the
vast majority of users mean when they enter "pkg install foo"? Users
should be able to override it, but the packagers are the ones who need
to think about it by default.
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.
Um, that's going to happen no matter what. If you install a package, the
packager of that package decides what's going to appear on your system.
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.
I agree, intent might change over time. So might search, or history, or
actions. It's our job to make it so that those changes work with
backward compatibility where possible, and where not possible, to make
the packager's burden as small as possible. The only way we can
absolutely ensure that things won't change out from someone is not to
change.
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.
So explain how you'll handle a packager obsoleting a package and
replacing it with two packages, the main app, a library, and a package
containing a supporting binary (one that's necessary to run the main
app). The app package should get the intent that the user installed it
directly, the library and supporting binary package should not. How do
we detect that?
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?
I was suggesting they be allowed to mark an individual package. I'm not
even fundamentally opposed to your suggestion of a command line flag to
propagate dependencies, it just doesn't solve the problem that giving
packagers this ability does.
To me the huge benefit of being able to control this now to avoid the
coordination issues outweighs possible cumbersomeness if done right.
I disagree unless you suggest a better interface for users. We have to
assume that packagers have a basic understanding of how the packaging
system works. That means that, by default, we try to do the right thing
and expose more interfaces for more sophisticated packagers. I'm not
opposed to giving users the ability to do whatever they want with
intent, but that doesn't replace the packager's responsibility to
package their software correctly.
[snip]
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.
Basically, I'm opposed to expanding intent without substantial reasons.
When we decide we need another piece of information we can start
recording it and attempt to reconstruct it from the history. Otherwise,
I think we go the route of just keeping all history because any and all
of it might be info we someday need. Assuming that's not the direction
we go, then intent will almost certainly be a limited subset of history.
I question whether version info needs to be in there now, but I don't
care enough to fight to keep it out for the moment. Since it will likely
end up in a different place, it likely won't be part of the initial
phase in any case.
Cheers,
Brock
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
