Seems reasonable. Thanks.
Tom
Brock Pytlik wrote:
Tom Mueller wrote:
Brock,
This seems like a good design and will certainly be helpful,
especially the parts about updating the catalog on set-authority
commands.
One question: for image-update, you say, "For each installed package,
if it was installed with a specific authority..." How will this be
determined? From what I've been able to tell, the "installed" file is
written exactly the same whether a package is installed with or
without an authority being specified on the command line. And I don't
see anywhere else where the authority for a package is saved. Would
this design involve a change to the format of the installed file?
Tom
Good question. For now, we'll use what we have. We know which authority
the package came from and whether or not it was the preferred authority
when it was downloaded. That covers "pkg install foo" and pkg install
pkg://AUTH/foo" where AUTH is not the preferred authority. Once we have
the mechanism to distinguish between the first command and naming the
preferred authority explicity or installing from an alternate authority
because the preferred repo didn't have the package, we can update this code.
For reference: (local is a non-preferred authority)
1)pkg install foo (from preferred auth): _PRE_ipkg
2)pkg install PREF_AUTH/foo: _PRE_ipkg
3)pkg install foo (from non-preferred auth): local
4)pkg install NON_PREF_AUTH/foo: local
For now, 2 will be treated as if it was 1, and 3 will be treated as if
it was 4. When the rest of the packaging system can tell them apart,
then this code can br changed to take advantage of that.
Brock
Brock Pytlik wrote:
Several bugs have been filed about pkg not automatically updating its
catalog at the right times (1540[1]) or having issues because and
authority isn't available when it's needed (1331[2], 2886[3]). I've
also heard from Bart that catalogs should be updated on any pkg
command which would change the installed packages. I'd like to gather
thoughts on this plan to make sure I'm headed in the right direction.
Whenever an authority is created or its origin changed, we should
attempt to update the catalog for the new repository or origin. If
the update fails, we'll leave the changes in place, but print out a
warning message. If the origin was changed, the warning message will
include previous origin. If the preferred authority changes, I think
we should probably refresh the catalog of the new preferred authority
as well.
For pkg install:
1) If a fmri with the version including the timestamp is given, no
catalog refresh will be done.
2) Else: If the fmri specifies an authority or the package was
previously installed from a specific authority, then that authority's
catalog will be refreshed, but no others will. If that authority is
unavailable, installation will fail.
3) Else: The catalogs for the preferred authority and the authority
the package was previously installed from will be refreshed. If
neither authority is available, the install will fail. If at least
one of the authorities is available, then installation will proceed.
For pkg image-update:
A list of authorities requiring refresh and a list of authorities
which are optionally updated will be created. For each installed
package, if it was installed with a specific authority (case 2 above)
then the authority is required to be refreshed. Authorities from case
3 will fall into the optional list. The preferred authority is always
added to the required list.
In order for the image-update to proceed, the catalogs of all
authorities in the required list must be successfully refreshed.
Attempts will be made to update the catalogs of the authorities in
the optional list, but failure will not derail the image-update.
Possible additional behavior available via command flags:
Allow image-update to proceed even if not all authorities in the
required list are available.
Provide a specific list of authorities which are the only authorities
that should be consulted for the image-update.
So that's the current idea. Please let me know what you think.
Thanks,
Brock
[1] http://defect.opensolaris.org/bz/show_bug.cgi?id=1540
[2] http://defect.opensolaris.org/bz/show_bug.cgi?id=1331
[3] http://defect.opensolaris.org/bz/show_bug.cgi?id=2886
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
