#637 approval for a 'docker-latest' package on fedora
Closed: Fixed None Opened 7 years ago by lsm5.

OpenShift (and perhaps others) depend on stable versions of docker, which means we aren't really free to upgrade the 'docker' package in fedora whenever upstream docker releases a new version.

The 'docker-latest' package will allow us to upgrade docker to the latest upstream, while projects like OpenShift can continue using the more stable versions in the 'docker' package

I have filed a review request here: https://bugzilla.redhat.com/show_bug.cgi?id=1352141


Usually the strategy would be to introduce a "compat" package † for your slow-moving consumers that would enable you to keep updating the main docker package.

I think I would prefer you introduce "compat-docker" and switch OpenShift to depend on that. This way users of the main docker package do not have to be made aware of this new package and existing documentation does not need updating.

https://admin.fedoraproject.org/pkgdb/packages/compat*/

Also if you don't want to go that way I'm mostly fine with docker1.12 package. Using -latest in a package name is only going to confuse everyone as time moves inextricably forward.

I'll move this to the meeting for tomorrow, but will very likely only +1 with a name change.

Lokesh, I'm fine with compat-docker. we can add conditional logic to the openshift packaging to require that rather than docker on Fedora.

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2016-07-07/fpc.2016-07-07-16.00.txt):

  • 637 approval for a 'docker-latest' package on fedora (geppetto,


    16:12:47)
  • ACTION: New plan follows
    https://fedoraproject.org/wiki/Packaging:Naming#Multiple_packages_with_the_same_base_name
    and thus. doesn't need an exception. (geppetto, 16:21:41)
  • ACTION: Packages can skip reviews if they are just older versions of
    reviewed packages. (+1:5, 0:0, -1:0) (geppetto, 16:30:32)
  • ACTION: Make compat package naming a MUST (+1:5, 0:0, -1:0)
    (geppetto, 16:39:45)

I always thought that compat- packages are for backward compatibility with external repositories (and this is definitely undocumented/underdocumented). Is this the case? Or are you speaking about versioned docker package?

Replying to [comment:5 vondruch]:

I always thought that compat- packages are for backward compatibility with external repositories (and this is definitely undocumented/underdocumented). Is this the case? Or are you speaking about versioned docker package?

After discussion, we agreed it should be a versioned docker package in line with the guidelines cited in the above ACTION item.

Thanks james, mbooth et.al. for discussing and deciding on this.

I just wanted to double-check that if we're going the route of having the version number with the base name, we could potentially end up with multiple packages like docker1.12, docker1.13, docker2.0 and so on, with only a few packages being actively used at any given point in time.

So, do you suggest we create multiple packages with docker%{version} format and retire the ones that are not being used anymore, or are there cheaper ways to getting around this?

Replying to [comment:4 james]:

  • ACTION: Packages can skip reviews if they are just older versions of
    reviewed packages. (+1:5, 0:0, -1:0) (geppetto, 16:30:32)

So newer packages with same base name will need reviews, correct? Also, should the default package 'docker' always be the newest possible version compared to docker+version packages? Or can the 'docker' package be the oldest or intermediate version?

For example: can we have
docker at 1.11
docker1.10 at 1.10.3
* docker1.12 at 1.12.0

or should it be
docker at 1.12.0
docker1.11
* docker1.10

I really am not crazy about this, and think we should discuss it with Product management since this will end up something very different then is on RHEL and Centos.

We could rethink these issues in these distributions. The problem is going to be on atomic host, in that we want to ship two versions of docker not N versions of docker.

Replying to [comment:8 lsm5]:

Replying to [comment:4 james]:

  • ACTION: Packages can skip reviews if they are just older versions of
    reviewed packages. (+1:5, 0:0, -1:0) (geppetto, 16:30:32)

So newer packages with same base name will need reviews, correct? Also, should the default package 'docker' always be the newest possible version compared to docker+version packages? Or can the 'docker' package be the oldest or intermediate version?

It's not just the basename, but the same package. The assumed process is something like:

  1. review XYZ-1
  2. ship XYZ-1 in Fedora
  3. update to XYZ-2 in Fedora
  4. Now need both XYZ-3 and XYZ-2
  5. ship XYZ2-2 in Fedora (review not needed, as it's basically the same as 3
  6. update XYZ-3 in Fedora.

...having the versioned package be newer would be weird, in Fedora, but if you needed that I guess we'd probably allow it (but we didn't vote to automatically allow that).

For example: can we have
docker at 1.11
docker1.10 at 1.10.3
* docker1.12 at 1.12.0

or should it be
docker at 1.12.0
docker1.11
* docker1.10

Yeh, the later would make much more sense and generally do the right thing, in Fedora.

Replying to [comment:9 dwalsh]:

We could rethink these issues in these distributions. The problem is going to be on atomic host, in that we want to ship two versions of docker not N versions of docker.

I'm not sure I understand the problem here ... I'm assuming you'd drop old versions you didn't want to maintain anymore, so it's unlikely you'd have more than 2 versions of docker at once in a single distro. and atomic isn't required to ship all of them even if you do have 3+ in F24 (they can require docker and <openshift-dep>, and then would get just one more via. deps).

One thing to think about is that the newer versions of docker stores data in /var/lib/docker-latest while the current version of docker points at /var/lib/docker We want to be able to update these packages independently. But keep the storage the same.

docker-1.10.3, docker-1.11.1, docker-1.12 would continut to use /var/lib/docker
And
docker-latest-1.10.3, docker-latest-1.11.1, docker-latest-1.12 will use /var/lib/docker-latest

If we switch to this new model, I guess we would need to have docker1.11 and docker1.12 replacing each other, and still using /var/lib/docker-latest

We wanted to treat these as two independent packages, not N independent packages.

So ideally I'd say you'd be better having:

{{{
docker use /var/lib/docker
docker1.11 use /var/lib/docker-obs
docker1.12 use /var/lib/docker-obs
etc.
}}}

...or something. However, there's no mandate in policy on filenames/dirnames like that so for compatibility you could go with:

{{{
docker use /var/lib/docker-latest
docker1.11 use /var/lib/docker
docker1.12 use /var/lib/docker
etc.
}}}

...and could even put a docker-latest virtual provide in the main docker package, so the same commands/requires will work across distros. too.

If we switch to this new model, I guess we would need to have docker1.11 and docker1.12 replacing each other, and still using /var/lib/docker-latest

Yeh, if you have to.
I was mostly expecting that you wouldn't major version bump the obs docker variant, so you'd only need one "old" package. But, yeh, obsoletes would work there if you needed to.

We wanted to treat these as two independent packages, not N independent packages.

I understand, and if you'd still prefer some other naming scheme we can revisit that at this/next weeks meeting (just ping someone). It just seemed like it'd been resolved to use the more normal schemes in the ticket, and we voted to allow those to go through anticipating that more will happen in the near future.

My personal main concern with the docker-latest package name was that of it still being around after F25/F26 and referring to a non-latest upstream version anymore, it's much snaer to label either package for the usecases expected (Eg. docker-obs for the older one, or docker-user for the newer one -- or anything, just not -latest or -newest or something). Of course other FPC members might feel differently.

I would like to present at that meeting. Who do I contact to get on the agenda? When is the meeting?

I'll add it to the meeting schedule, which will go out tomorrow. Meeting is at 12:00 east coast time on Thursday in #fedora-meeting-1.

12:00 Thursday works for me.

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2016-07-14/fpc.2016-07-14-16.00.txt):

...going to put it on the schedule for next week too, or you can post here.

Replying to [comment:17 james]:

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2016-07-14/fpc.2016-07-14-16.00.txt):

...going to put it on the schedule for next week too, or you can post here.

For the record, and as I said in the meeting last time, I am also against having a "docker-latest" package. IMO, the "docker" package should be the latest and an older version should be named "docker-compat" or "dockerX.XX" as discussed above.

I've written up the bit from comment 4. I couldn't really find a good place for it so I put it at the top of the ReviewGuidelines document.

Announcement text:

The review process document has been ammended to note possible exceptions, and to indicate that review is not needed in certain situations where a different version of an existing package is being added.
https://fedoraproject.org/wiki/Packaging:ReviewGuidelines#Package_Review_Process
https://fedorahosted.org/fpc/ticket/637

Replying to [comment:20 tibbs]:

Just to confirm, this means FPC has accepted a 'docker-latest' package, correct?

Also, do I need to do a separate review for this, or is it not needed? I'm not sure how to request new dist-git for 'docker-latest' without review as the 'Request new package' seems to require it.

Thanks

Well, it means that FPC made it so that you didn't even have to ask.

Actually requesting the repository is kind of annoying because you can't skip entering something for a bugzilla ticket. I thought I had written something up about that but as usual, if I did I either forgot to actually save the page or the wiki ate it.

Let me fix something up.

I created https://bugzilla.redhat.com/show_bug.cgi?id=1376885 which you can uses as a dummy ticket when filing your pkgdb request. Note to limb, since you'll probably be processing these: I have no idea what the automatic checkers will actually do in this situation, but I'm sure there will be at least some yelling.

I updated the review process document (https://fedoraproject.org/wiki/Package_Review_Process) to reference that bug, and cleaned up that document a bit in the process.

I also realized that the guidelines as written actually mandate using versions and don't actually permit suffixes such as "-stable" or "-latest". I went ahead and updated that document to indicate that (since we obviously intended to permit it) and to reflect the issues the committee had with the use of the "-latest" suffix.

https://fedoraproject.org/wiki/Packaging:Naming#Multiple_packages_with_the_same_base_name
https://fedoraproject.org/w/index.php?title=Packaging%3ANaming&diff=471444&oldid=468930

If any FPC member has an issue with this change, please let me know and I'll back it out and present the change formally instead. And of course feel free to fix anything I typoed.

Thanks tibbs. I just created a pkgdb request using that bz.

I should have mentioned that said bug does have instructions you should follow so that whoever is processing the pkgdb requests won't be bewildered and can at least check the requested name versus the base package name. I'll fill that out in this case.

Metadata Update from @mbooth:
- Issue assigned to tibbs

7 years ago

Login to comment on this ticket.

Metadata