Closed Hackebein closed 4 years ago
After thinking about it. We should not replace system files. This is not the job of mailcow.
I don't wanna disrespect someone. I understand what the meaning behind it and the good intentions. The more I think about it, the less attractive this update function seems to me. This look very ugly. Even my recommendation with the using of file
looks ugly to me now.
We should use docker-compose inside a container or only check the docker-compose version and warn the user that the current used version is outdated.
It is 1.24.1 because 1.25.0 was broken with mailcow. I'm still not sure it works, but it should. I don't want to risk it, just because someone is unhappy to not be on the latest of the latest compose binaries. I really want to wait for 1.25.>0.
So... it worked absolutely as intended. That's the whole point of me controlling that version. Instead of everyone running into the knife, we were able to stop broken mailcows.
If you don't like it: change the update script on your system. :)
PS: It was the first time ever, we didn't just read the latest version from GitHub and forward it. This was never something static we needed to update manually. If you want to install it from an outdated repository, make sure you read all issues on here why that's a bad idea. It is like people using Rspamd from the Debian repository. It is broken as fuck, but some still consider it a better alternative, because it's in Debians repository. It isn't. :)
@andryyy do you recall what the issue was with 1.25.0? I've been running it for about two weeks with no noticeable issues, happy to do some testing to confirm this if you like.
Yes. The build flags. I moved them. I want to wait for 1.25.1 anyway.
As of now the update script still overwrites my docker-compose in alpine linux with a version that is not correctly linked. So it basically breaks my systems docker-compose installation. Should I open up another issue for that?
As said in the IRC I forwarded it and @andryyy thought about adding a skip option to the update script.
It is implemented now.
https://github.com/mailcow/mailcow-dockerized-docs/blob/master/docs/i_u_m_update.md
Please try to answer all questions. If you cannot, don't just delete it. If you completely ignore or remove the whole template, your issue is either closed or ignored, too. :( This is (not only) because we are evil. Many awesome mailcow supporters don't bother to reply to an issue, when crucial information is missing. Especially when it could have been answered by using this issue template. We need as much information as possible. Please post all logs, do not copy that one line you think may be interesting. Copy the whole bunch and remove sensible information. :) Thank you!
Prior to placing the issue, please check following: (fill out each checkbox with a
X
once done)Description of the bug: What kind of issue have you exactly come across?
https://github.com/mailcow/mailcow-dockerized/blob/master/update.sh#L399
https://www.servercow.de/docker-compose/latest.php
returns 1.24.1 instead of 1.25.0. 1.25.0 is out for 13 days now.https://github.com/mailcow/mailcow-dockerized/blob/master/update.sh#L403 This is not working for alpine linux. alpine linux needs "run.sh" instead of "docker-compose-$(uname -s)-$(uname -m)"
I would recommend the use of
file
:https://github.com/mailcow/mailcow-dockerized/blob/master/update.sh#L395 Maybe we can replace this with the use of
file
. Just because the pip project docker-compose is (not) installed does not mean that we also use this binary in our update process.alternative we could use
docker-compose
inside a container. Then we never need to update a system resource/binary and can use the newest version ofdocker-compose
Reproduction of said bug: How exactly do you reproduce the bug?
System information
Further information (where applicable):
docker version
)docker-compose version
)General logs: