On 06/27/12 14:57, Tim Foster wrote:
On 06/28/12 08:54 AM, Brock Pytlik wrote:
On 06/26/12 20:30, Tim Foster wrote:
https://cr.opensolaris.org/action/browse/pkg/timf/pkglint_fix_dep_obsolete/webrev
The changes still lgtm.
Cool, thanks.
I did have a couple of question though. Will this prevent us from ever
obsoleting a package that another package has been renamed too?
Well, no in that pkglint itself obviously doesn't stop you doing
anything :) The recommendation though, is to obsolete all of the
now-renamed packages at the time you're publishing the final obsoleted
name. (at least that's the recommendation in the OS/Net consolidation
README.pkg) and so this behaviour would enforce that correctness.
I think
this would work at publication time since we'd only be evaluating the
obsolete package, and not the renamed package (which would be part of
the reference repo). However, wouldn't these packages, when linted all
together in a repo, fail?
Yep.
I guess I'm imagining the following scenario where each separate
publication/pkglint run is separated by ----:
A@1 is published.
----
A@2 is published with a rename to B (or B@2)
B@2 is published normally.
----
B@3 is obsoleted.
Each of these publications, I think, would pass pkglint, but when I do
pkglint over the repository, it lints (I think) the latest version of
each package so A@2 and B@3 would be linted. Since B@3 is now obsolete,
A@2 would trigger a lint error, right?
Correct, though there are pkglint flags to have it lint older versions
of packages (actually packages up to a certain build-version
threshold) which would allow you to lint the state-of-the-world up to
@2, which in the example you describe, would result in no errors from
pkglint.
If what I've outlined above is how things would work, then I'm
concerned. I'd think either we'd need to not make this an error at all,
or have the publication of B@3 fail pkglint since something has been
renamed to B (which would in theory prevent us from obsoleting a package
that's been renamed to, also something I think isn't a great outcome).
What have I misunderstood?
I think the lint-up-to-a-specific-version flag fixes things in this case.
Otherwise, we certainly could downgrade the error to a warning, which
would result in pkglint returning with a 0 exit-status, allowing
multi-step publication as you describe, and trust that at some point,
the developer will actually obsolete all of those renamed-ancestors.
Ok. I think the solution to my issue was what you outlined in the first
answer which is:
"When you obsolete a package, you also have to publish new, obsolete,
versions of all packages which have been renamed to it."
This lint rule will help us find such packages. If we don't have this
best practice in the dev guide (and it didn't seem to be in the version
I found just now), we should probably add that recommendation.
Thanks,
Brock
cheers,
tim
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
