Brock Pytlik wrote:
Shawn Walker wrote:
I don't think you're off your rocker, I just think we lack a system
for recording user intent so that this isn't an issue.
I agree we lack that system, but where we disagree is what the right
response is given that. I believe the right thing is to be conservative,
and not move people off the publisher that they may, or may not, have
chosen for a package.
I'd agree with that if we didn't already have behaviour today that would
move a user off the publisher that they may or may not have chosen.
Remember, the primary issue here is the inconsistency, and the fact that
for a very long time now, we've tried to indoctrinate users with the
belief that the preferred publisher is always used for package operations.
Without this change, the only way for a user to get out of the mess
would be to uninstall all packages from a given publisher, and then
reinstall them so that the version from the preferred publisher would be
used; that doesn't seem very friendly.
I definitely agree with you, but until we have a way to record user
intent, or until we have a more granular approach for "preferred"
publisher, I think it has to be fixed -- otherwise, users are just
going to be justifiably confused.
I believe this is especially true because, right now, users often have
/release and /dev as separate publishers, and because of the issues
surrounding pending/ and contrib/.
I'm not certain how release and dev come into this, so I'd need some
examples of how users have gotten confused on this front. At first, I
thought I saw how pending and contrib would cause issues, but now I'm
much less certain, so I'd like examples for that setup as well.
Well, much of it depends on how pending/ contrib/ and dev/ or release/
end up relating to each other. For example, one of the proposed plans
has been that software in contrib/ could eventually move to dev/ or
release/.
For an example, imagine that an image has the following repositories:
pending/
contrib/
release/ (preferred publisher's repository)
We then have two cases I see as a failure:
* A user initially installs foo from pending, which later is removed
from pending/ and published to contrib/. Right now the user won't get
upgraded to the final version in contrib/ when they perform an
image-update. Without a more granular preferred status, I don't know
how to solve this one.
* A user initially installs foo from contrib/, which is later promoted
to release/ and newer versions start getting published to release/
insted of contrib/. Right now the user won't get upgraded to the newer
versions in release/ even though that is their preferred publisher when
they perform an image-update. This can be solved by using the preferred
publisher to determine the software source.
Another example might be this, imagine that a *user* image has the
following repositories:
glassfish-devel/
glassfish-release/ (preferred publisher's repository)
User installs glassfish-2.0 from glassfish-devel/ (pretend they don't
have to do this explicitly since glassfish-2.0 doesn't exist in
glassfish-release/). Later on, the final version of glassfish-2.0 is
published to glassfish-release/ and then incremental bugfix versions of
glassfish-release are *only* published to glassfish-release/. The user,
when performing image-update will never get those newer versions.
Of course, a lot of these problems are only happening because the user
essentially has the same publisher on their system more than once. If
the user were forced to switch between repositories for that publisher
instead to gain access to different versions, then this problem wouldn't
exist (though a new set of problems might).
Lastly, I'd like some comment on the version issue. I'm willing to
accept for the purposes of this discussion that "flash" or "gcc" should
be able to fill the same role on the system no matter which publisher
they come from. (I think that's debatable, but it's not relevant for
this discussion.) I think expecting publishers to all get together and
agree on a version scheme for each package isn't realistic. Let's take
flash as an example since it's in the extra repo. We've published it as
[email protected] and [email protected] (roughly). Suppose someone else started their
own repo to package flash before we got around to it (which is what we
want people to do), and they published it as [email protected] and
[email protected] (again, roughly). Would we have changed our versioning
scheme to work with theirs? Would we have told them to change theirs to
match ours (which they couldn't do)? I think once you choose a publisher
to get your packages from, you're somewhat tied to their updates unless
you manually intervene.
I don't feel qualified to comment on the version issue. However, I can
tell you that my understanding is that the package stem is considered
sufficient for equivalence. It's something I brought up during last
year's package namespace discussion.
You've also brought up some good points about version comparison as
well, but I think that really falls outside the scope of the change
being proposed here since it applies to install and not just
image-update as well.
I grant that everything I've pointed out is hypothetical, but my
understanding is that part of what we're looking for is to have
community run and driven repos, and those aren't necessarily going to
adhere to our, or others, versioning schemes. I would probably argue
that the right thing to do when switching preferred publishers (for
packages that weren't installed from a specific publisher), is replace
the existing package on the system with the newest one with the same
name from the new preferred publisher.
I think my point is that until we give the user a better way to control
the switching of software sources for packages (publishers), always
using the preferred publisher status is empowering the user to make
those decisions (in a consistent manner) instead of the hodge-podge we
have at the moment.
I think you'd agree at the very least that the change for bug 8616 is
correct?
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
