On 9/30/21 23:34, Tom Braack wrote:
> yes, I've read that.
> I created that to specifically provide the 1.x release line of docker-compose, as the official package was recently bumped to 2.x, which has major incompatibilities.
> If having such a package is not the right way, what's your suggestion for providing older, yet widely used versions?
>> On 30. Sep 2021, at 21:34, notify(a)aur.archlinux.org wrote:
>> aminvakil  filed a deletion request for docker-compose1 :
>> The submitted PKGBUILDs must not build applications already in any of
>> the official binary repositories under any circumstances. Check the
>> official package database for the package. If any version of it
>> exists, do not submit the package. If the official package is out-of-
>> date, flag it as such. If the official package is broken or is lacking
>> a feature, then please file a bug report.
>>  https://aur.archlinux.org/account/aminvakil/
>>  https://aur.archlinux.org/pkgbase/docker-compose1/
1.x is not going to be maintained anymore (except security fixes), so
I'd suggest using docker-compose-1.29.2 from your local cache until you
change your yaml files and make them compatible with 2.x.
Also --compatibility is a flag on 2.x.
capSAR  filed a deletion request for multimc-git :
The multimc-bin package is the official one which will update the
binaries itself, also supporting Microsoft accounts and the
Development/Release version selector. It is confusing to have multiple
packages for the same program when one is already being maintained by