On 24/06/2009 19:06, Danek Duvall wrote:
On Wed, Jun 24, 2009 at 04:08:45PM +0100, Christian Kelly wrote:
An obsolete package is a version of a package which no longer delivers any
meaningful content, compared to previous versions. Marking a package
obsolete indicates that a repo is no longer in the business of delivering
any bits under that name.
Just to be 100% clear here. Are you saying that a package version
can only be marked as obsolete at publish time? That existing
package versions in the repo cannot be flipped to obsolete?
Correct.
We, the Source Juicer team, will be promoting packages from one repo
to another. So, someone submits a package, it gets built and
published into /pending. It's reviewed and gets promoted into
/contrib.
Normal users will be fine, they'll just have /contrib set. Our
developers, however, will have both repos set.
I'm thinking that, at the point of promotion, we must publish an
obsolete package version to the /pending repo, then publish the new
package to /contrib.
Why publish the obsolete package? Wouldn't you just republish the approved
package to /contrib and be done with it? Or is the point of /pending that
every package in it is still going through the approval process and has yet
to be approved or denied? (That seems a bit strict to me.)
We only put packages in /pending so there's somewhere where developers
can get them to qualify them. The 'good' ones go on to /contrib, which
is where users get them. Once they've been promoted, the packages in
/pending should not be used by anyone. What we really want is to *move*
packages.
What will be the behavior for a user that already has the package
installed? From what you've described, it will, at least un-install the
/pending version. I imagine that the user will have to do a 'pkg install
foobar' twice.
Well, it depends on what the user actually does. Mere publication to the
repo won't do anything at all to the user's system. :) If they do an
install of the package to upgrade it alone, or do an image-update that
pulls the new version in, then the newest version allowed by the
constraints on the system will be pulled in. If that's an obsolete
version, then the package gets uninstalled. If that's not an obsolete
version, then they'll just get that version. I think in practice the only
thing you'd get out of publishing an obsolete version to /pending is the
folks that have /pending but not /contrib would see packages disappear.
But that's a user configuration problem, IMO.
Right :P I mean on a pkg install here.
The behavior we want is:
0. Developer has /pending and /contrib set as publishers
1. Developer submits package foobar, it builds and is published to
/pending
2. Developer does a 'pkg install foobar' to test it
3. Package gets promoted (republished to /contrib)
4. From now on (for everyone) a 'pkg install foobar' always gets
/contrib foobar
So, I thought obsoletion might be the answer to this.
_Christian
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
