On Jun 23, 2009, at 2:34 PM, Danek Duvall wrote:
On Mon, Jun 22, 2009 at 08:25:08PM -0500, Shawn Walker wrote:
Danek Duvall wrote:
Publication Changes
-------------------
As mentioned above, the obsolete attribute will need to make its way
into the catalog, so the publication server code will need to
parse the
manifest looking for this attribute. Given the upcoming catalog
format
changes putting dependency information into the catalog, this won't
present any extra burden on publication.
Given the problems with depending on an obsolete package, the server
should not allow such dependencies. This should be thought of as a
distro-wide (or at least repo-wide) flag day. In the case that a
package is being renamed, the dependent packages should be changing
their depend actions to match the new name, and in the case that a
package is simply being EOLed, any other package depending on it
should
simply be treated as a bug.
- server should expand dependencies to unambiguous stems (or fail
add?)
- the server might want to refuse publication of an obsolete package
with adjacent versions (no non-obsolete version "in between")
Currently, this could cause issues with the republication mechanism
used by pkgrecv. However, since it is already known that the
current mechanism for pkgrecv is not viable long-term, this may not
matter.
But, that may mean that this restriction either has to be optional
from an api perspective, or that the republication mechanism used by
pkgrecv will have to be re-implemented first before this restriction
is put into place.
I'm guessing that the problem here is that pkgrecv may not publish
packages
in any guaranteed order, thus possibly publishing two "adjacent"
obsolete
versions even though a non-obsolete version may be published in
between
them a bit later?
Well, that too. But I was thinking more of the case where we
backpublished an older package version using pkgrecv that had been
obsoleted in a later version.
11 install an ambiguous name where only one match is non-obsolete
???
12 upgrade a package to an obsolete version with a dependency on a
package
which has a (potentially) ambiguous name
???
Is the confusion about what "ambiguous name" means? That's the first
specific example: what do you do when you've packages named
"netbeans" and
"developer/netbeans" and you ask to install "netbeans"? These cases
say
"use the non-obsolete one, if precisely one such exists".
Ah, actually, I was expecting the test case detail below these
examples or a note saying they matched another example case. Unless
my mail client munged the message, the original posting you sent out
didn't anything but the "bullet points" for 11 and 12, but all other
points had text beneath them explaining the case. I had thought they
were left out accidentally.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
