On 06/27/12 17:46, Brock Pytlik wrote:
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.
Actually, I think I still have an issue here. I think my issue is that
in the 3 generations of publication outlined above, when I ran pkglint
on B@3 before publishing it, I wouldn't get a pkglint warning, because
A@2 is a "reference" manifest. What I'd like to see (and I don't know
how insane of a request it is from an implementation point of view) is
that when I linted B@3 against the repo which contained A@2, I would get
a lint warning like "about to obsolete a package that's the target of a
rename. Either don't obsolete this package or obsolete A". Is it
reasonable to add what's essentially the mirror of the rule you've added?
I'm not thrilled that even though pkglint was clean every time I did my
publication, I can end up with a repository that's not pkglint clean. I
don't view lint-up-to-a-specific-version as a fix for this because the
repo is in a particular state, it's not the case that B@2 was the end of
B's publication. If it makes things clearer, imagine that instead of
publishing A@1 and A@2, I published A@101 and A@102, then pkglint at a
version is kinda meaningless. Also, if it's pkglint at this
incorporation (instead of version), then pkglinting against the latest
incorporation which includes A@2 and B@3 would still fail.
In short, now if I want to ensure that I have a pkglint clean
repository, it's not sufficient to pkglint all my packages against that
repository and each other any time I'm publishing a group of packages.
Instead, I have to wait until all the packages have been published, then
run pkglint over the repository and that repository now must be a
staging repo (that's a duplicate of my full repo) since I may need to
roll back publication of some packages to fix some pkglint issue.
Thoughts?
Brock
Thanks,
Brock
cheers,
tim
_______________________________________________
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
