I take it that the docker.io version number is lower than the existing docker package?

Replying to [comment:1 toshio]:

I take it that the docker.io version number is lower than the existing docker package?

Yeah. They're targeting a 1.0 release in October. http://blog.docker.io/2013/08/getting-to-docker-1-0/.

Replying to [comment:1 toshio]:

I take it that the docker.io version number is lower than the existing docker package?

Yes, the existing docker is 1.5. The docker(-io) we're looking to package is 0.5.3 (or 0.6.0)

The standard solution that wouldn't require any guideline exception would be to use Epoch. docker (io) package starts with Epoch: 1. wmdocker package has the normal Obsoletes Provides:

Obsoletes: docker <= 1.5-RELEASE+1
Provides: docker = %{version}-%{release} # or perhaps Provides docker = 1.5-RELEASE in this special case... we'd be safe, though, as long as wmdocker didn't introduce an epoch that made it into the Provides.

I won't say that this is what Epoch was created for but it is an appropriate use of it (I think I've seen it used in the wild for this purpose a couple of times).

Doing this via an exception.... if Andreas is okay with the release notes route, I might be okay with voting for an exception but I'm on the fence... epoch isn't the best thing in the world since it is easy to forget about sometimes and is with you forever but it is there to be used if the situation warrants it and this might be such a case.

Thanks Toshio. I'm glad there's more than one possible path here. Andreas, what do you think about the release notes approach? I have a preference for that because I know how painful Epoch can be.

Well I was thinking about the Epoch approach myself at first. Maybe I'd be cleaner however to take the release notes approach. I will prep a renamed package tomorrow and put it up for rereview.

We discussed this at today's meeting and didn't think that the specific exception asked for here was appropriate. Release notes are a poor solution for people who are actually going to want to upgrade the wmdocker package. However, we did discuss two ways that the proper behaviour could be implemented. Epoch in comment:4 was evaluated, should work, and does not require an exception. An Epoch-less route requiring a smaller exception was discussed:

'''Proposal''': Allow the wmdocker rename to omit the Provides: docker [It will keep the Obsoletes: docker for the standard 2 fedora releases]. This means that the new docker package can go in as docker.io now with a Provides: docker and be renamed to docker when the Obsoletes are removed in wmdocker.

The idea of the proposal is that it will:

• Allow people updating from a previous docker package to get the wmdocker package (The wmdocker's Obsoletes: docker <= $PREVIOUS_EVR will take care of this)
• Allow people doing yum install docker for the first time to get docker.io (the Provides that's only in docker.io and not in wmdocker will take care of that).
• Allow people doing yum upgrade with the docker.io package installed to keep getting docker.io updates (not be switched to the wmdocker package)
• Avoid epoch in both the docker-io package and, in two releases, in the docker package that docker-io is renamed to.

Voting at today's meeting was:

+1: tibbs|w, geppetto, abadger1999, SmootherFr0gZ

We need one more +1 from any of the following to pass: limburgher, racor, Rathann, Remi, spot

+1 from me.

Thanks limb! That's +5.

awjb, mattdm: You are approved to use the wmdocker-has-provides-but-not-obsoletes solution if you so choose.

Thanks everyone.

Thank you :)

Rename Review: https://bugzilla.redhat.com/show_bug.cgi?id=1005459

sorry to bring this up so late, but in the current rawhide (f21), would it be feasible to drop the existing docker package (given that wmdocker exists as well), and have docker-io renamed to docker? or is it gonna break stuff and have people confused as to what 'docker' package means?

i'm seeing the docker-io to docker rename is scheduled for f22, but looks like people would much rather have it sooner (if doable, of course) :)

sorry if i missed anything. Thanks!

If I remember correctly, the existing docker package can be (and should be) dropped but docker.io can't be renamed until the Obsoletes: docker is dropped from the wmdocker package. That Obsoletes can't be dropped until the two releases have passed because we don't people who have installed the existing docker package in a released Fedora to get upgraded to the docker(io) package instead of to the wmdocker package. (Once we pass the point where we don't support upgrades from that release of Fedora anymore the rename can then take place.)

Thanks toshio.

awjb, I have filed a bz here: https://bugzilla.redhat.com/show_bug.cgi?id=1043676

Sooo, moving to the next phase of this. As noted above, f22 will be after two releases (that is, f20 and f21), so we should be good to rename in rawhide. We can do the normal package rename/re-review process, but what happens after that since there is an existing docker dist-git? Will that get destroyed and recreated?

What happens to a) the existing still-valid f19 package and b) the history?

Because of a), we could wait until f19 end-of-life. But that doesn't help with b).

Might it be better to leave the source rpm as "docker-io", and generate (only) a binary sub-package with a name of docker? That's kind of kludgy, but should be mostly transparent to end-users and keeps the old docker package history. (Downside is in pkgdb and a little confusion if someone is looking for the source.)

Probably want to bring dgilmore into this conversation but from the issues you bring up, maybe something like:
Until f19 EOL's build docker as a subpackage of docker-io.
After f19 EOL rename the git repository on the server so that all our names are as we expect.

In addition to pkgdb being confusing before we rename, bugzilla will also be confusing. That's more of a concern for end users unfortunately... one reason it seems like only going with a subpackage for a limited time would be better.

Hey Dennis, seems like we have an idea of how to switch over what package is using the docker git repo that might work out for docker in comment:16. But if you have a better idea, that would be fine too. I think the concern is just wanting to preserve some of the package history when we switch the package name and we're trying to figure out the timing as well.

Not sure what's up here; FPC's bit in this has long been concluded. I guess if there's some trickery left to do involving git repos, someone should file an infrastructure ticket.