| Summary: | app-containers/docker-compose-1.x consider removal at the end of 2023-06 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | William Hubbs <williamh> |
| Component: | Current packages | Assignee: | Sebastian Pipping <sping> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | hydrapolic, sping, ulm |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://docs.docker.com/compose/release-notes/ | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
William Hubbs
2023-04-12 21:17:00 UTC
Hello William, frankly I'm not too happy about this ticket because: - Last time I checked, 2.x had issues that 1.x didn't have, for example: https://github.com/hartwork/jawanndenn/issues/332 I will need to re-evaluate that situation. - I have raised concerns over the deps.tar.xz approach of 2.x that I consider a security auditing transparency nightmare to you via e-mail on 2022-03-16. My tone was probably not the best, but I did offer help and I meant it. Have you receive that e-mail? Title was "docker-compose 2.x bundling issues". - I personally have 2.x masked locally and no motivation to switch to 2.x on Gentoo, as of today. - Before docker-compose 1.x gets unfixable CVEs or cannot be made to work with the oldest supported version of Python, I don't see any point in removing it, and it should be my call as the maintainer of the Python variant, before there is a strong reason to, if I'm not mistaken about protocol. What is your motivation for removal, why the rush? For now, please treat my reply as an explicit veto against removal of docker-compose 1.x. - PS: Debian bookworm, that is in hard freeze to go stable these days, has the Python variant package so at least some other distros will have the 1.x Python variant around long past June 2023. What do you think? Best, Sebastian I never found such end-of-life arguments convincing, because they don't mean that the older version is now suddenly and magically broken. There may be users using V1 in production environments (e.g. in a VM with another Linux distro) who want to test things locally before deploying. Why take that choice away from them? (In reply to William Hubbs from comment #0) > My thought at that point is that I will revbump docker-compose-2 so that > it is in slot0 and blocks slot 2. That should remove docker-compose 1 > from systems and re-locate docker-compose-2 to slot 0. This looks needlessly complicated. There is nothing special about slot 0, so why the slot move? If you're really going to remove V1 (but see above), then just package.mask its slot and send last-rites. (In reply to Sebastian Pipping from comment #1) > Hello William, > > frankly I'm not too happy about this ticket because: Hey Sebastian, I cc'd you on this bug because you are the maintainer of the 1.x branch. So thanks for responding. > - Last time I checked, 2.x had issues that 1.x didn't have, for example: > https://github.com/hartwork/jawanndenn/issues/332 > I will need to re-evaluate that situation. Please do this, I'm curious what you find. > - I have raised concerns over the deps.tar.xz approach of 2.x that I consider > a security auditing transparency nightmare to you via e-mail on 2022-03-16. > My tone was probably not the best, but I did offer help and I meant it. > Have you receive that e-mail? Title was "docker-compose 2.x bundling > issues". I can't find that email unfortunately, but I'll respond briefly here. Please send me another email if you want to discuss this further. The reasons we have the -deps tarballs in the first place are the size of the ebuilds and manifests as well as A being exported to the environment which breaks portage. Bug #721088 is open to address not exporting $A, but that hasn't been addressed. If A was not exported, I could list all of the dependencies in SRC_URI. But, if I do that, we will go back to multi thousand line ebuilds and manifests. Also, if we started tweaking the dependencies, it would end up being a mess to deal with because we would be essentially creating a fork which might not be supported upstream if we file bugs. For this reason, I don't know of any distros that are unbundling go dependencies. Another proposal was bug #883567, which would allow us to download the dependencies as part of the build, but as you see on that bug it was shot down. > - I personally have 2.x masked locally and no motivation to switch to 2.x > on Gentoo, as of today. The way things are currently set up, you can have both of them on your system if you want. docker-compose runs v1 and "docker compose" runs v2 since it is a subcommand of docker. > > - Before docker-compose 1.x gets unfixable CVEs or cannot be made to work > with > the oldest supported version of Python, I don't see any point in removing > it, > and it should be my call as the maintainer of the Python variant, before > there > is a strong reason to, if I'm not mistaken about protocol. What is your > motivation for removal, why the rush? For now, please treat my reply as an > explicit veto against removal of docker-compose 1.x. > > - PS: Debian bookworm, that is in hard freeze to go stable these days, has > the > Python variant package so at least some other distros will have the 1.x > Python > variant around long past June 2023. > > What do you think? > > Best, Sebastian As I said above, I specifically cc'd you to get your thoughts on this, so since you have concerns, I have no problem working with you. :-) Thanks, William Hi William, thanks for elaborating on the Go dependencies situation. (I experimented with EGO_SUM locally for the docker-compose 2.17.2 case now and I ended up with a 183067 characters long SRC_URI which is bigger than Linux' MAX_ARG_STRLEN (=131072). XZ compression gets it down to 18256 bytes. Maybe we need to use compression on some of these environment variables…) Does this ticket need anything more or can it be closed as "no current intentions for removal"? Best, Sebastian |