Hi,You describe the "sticky" attribute as a feature of the publisher, yet your examples and explanations seem to say this is actually an attribute of the individual packages.
I agree that using the publisher as the selection criteria to make a set of packages non-sticky would be a common case. Would it not also be a valid case for someone to make just one or a small set of packages not be sticky rather than everything from a given publisher?
Bart Smaalders wrote:
During SAT solver development, I will end up redoing a lot of the publisher selection code, and my trying to make sense of the current algorithms has led us to the following: In order to select packages from a variety of sources, pkg(5) supports the configuration of multiple publishers. We've started with the concept of a preferred publisher, but some ambiguity has arisen as to what should happen when publishers are deleted, added, etc. In addition, the single level of selection afforded by the preferred designation appears to be somewhat limiting; at the same time, the rules for selecting amongst multiple publishers of the same package need clarification rather than additional complexity. We propose the idea of publisher search order, starting with the preferred publisher. Adding a publisher adds a new publisher at the end of the search order; if a publisher is made preferred it is moved to the front of the search order. Deleting or disabling a publisher causes it to be removed from the search order. Re-enabling a publisher causes it to added at the end of the search order. When a package is nominated for installation without an explicit publisher being specified, the first publisher found in the search order to provide the package is selected. Once installed, subsequent updates to that package by default always occur from that publisher, even if a publisher earlier in the search order starts publishing a package with the same name. This behavior of a publisher is characterized as "sticky", and is the default. It can be disabled on a per-publisher basis, and such disablement is useful mostly for developers seeking to replace a portion of their packages w/ development versions. If a publisher is made "non-sticky", its packages are searched for as on initial installation on every update - no preference is afforded by the previous installation. Each selection of the publisher for a package is made independently according to the algorithms above; there is no implicit inheritance of publisher across dependencies of any type. The above suggests the following additions to the set-publisher subcommand of pkg:set-publisher [--search-before=publisher] [--search-after=publisher] publisherset-publisher [--sticky] [--non-sticky] publisher --search-before=publisherB publisherA causes publisher A to be movedfrom its current place in the search order to be just ahead of publisher B.--search-after=publisherB publisherA causes publisher A to be moved from its current place in the search order to be just behind publisher B. Specifying --non-sticky causes this publisher not to automatically be selected for all updates to packages already installed from thispublisher; instead, publishers searched earlier are automatically preferred.--sticky causes the original behavior to be restored for subsequent updates. Use cases --------- Normal user getting packages from pkg.opensolaris.org and datahavens.org: 1) Installs system as per usual, points preferred to usual best available publisher - say, pkg.opensolaris.org 2) Adds new publisher datahavens.org to acquire mplayer. Without specifying search order, new publisher is appended to the current order. Project Developer: 1) Installs system as per usual, points preferred to usual best available publisher - say, pkg.opensolaris.org 2) Adds new publisher "MyOwnRepo" pointing at his latest and greatest bits. Note that his repo is lowest in search order, but since his package names are unique no issues arise. Contrib User that prefers supported bits: 1) Installs system as per usual, points preferred to usual best available publisher - say, pkg.opensolaris.org 2) Adds contrib repo after p.o.o, and makes it non-sticky. 3) Adds packages from contrib as desired. 4) When and if packages move to p.o.o, they're automatically updated from p.o.o on the next image update or pkg install .... OpenSolaris developer: 1) Installs system as per usual, points preferred to usual best available publisher - say, pkg.opensolaris.org/dev 2) Adds new preferred publisher "MyOwnRepo" pointing at his latest and greatest bits; making it preferred places it first in the search order. 3) Pkg.opensolaris.org is made non-sticky to cause pkgs from MyOwnRepo to replace those from pkg.opensolaris.org on next update 4) If additional fresh bits are required, additional development repos can be added and placed ahead of pkg.opensolaris.org in the search order; in this way multiple consolidations can be kept at the bleeding edge.
--
~~~~\0/~~~~
Cheers,
Jon.
{-%]
========
If you always do what you've always done, you'll always get what you've always
gotten.
- Anon.
--------
When someone asks you, "Penny for your thoughts," and you put your two cents
in, what happens to the other penny?
- G. Carlin (May 12, 1937 - June 22, 2008)
<<attachment: jon_aimone.vcf>>
_______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
