You are not logged in.
Pages: 1
Hi guys,
I have tried many linux distributions but I must say that I really like Archlinux.
For this reason, I would like to understand if it is a distribution that can also be used at work to develop software.
When developing a project we are forced to use certain versions.
Let's take an example:
I need to install mariadb.
Currently on the repository there is the version 10.4.12
The project requires version 10.3.12 which is present in the Archive.
I take these steps:
1 Step
I go to the archive and download mariadb-10.3.122 Step
pacman -Qi --file mariadb-10.3.12-1-x86_64.pkg.tar.xz
I see the dependencies of this package.
Depend on
mariadb-clients = 10.3.12
inetutils
libsystemd
libxml2
ZSTDFirst question:
inetutils, libsystemd, libxml2, zstd packages
no version is specified. What does it mean?
Will they be downloaded automatically from the repository?3 Step
I check the package dependencies
mariadb-clients = 10.3.12 and I see that it depends on mariadb-libs = 10.3.124 Step
Install packages
mariadb-libs = 10.3.12
mariadb-clients = 10.3.12
mariadb-10.3.12What happens when I update with pacman -Syu?
They would be updated to version 10.4.12.
I don't want this, so I tell pacman to ignore it
mariadb-libs = 10.3.12
mariadb-clients = 10.3.12
mariadb-10.3.12
5 Step
in /etc/pacman.conf I add this
IgnorePkg = mariadb-libs mariadb-clients mariadbIf all the other packages that depend on mariadb.10.3.12 were updated, for example:
inetutils
libsystemd
libxml2
ZSTDWhat would happen to the system?
Do I have a misaligned situation?
Is it a correct practice or archlinux is a distribution created to always run the latest software available?
Thank you all
regards
Last edited by archdom (2020-03-01 12:46:14)
Offline
First question:
inetutils, libsystemd, libxml2, zstd packages no version is specified. What does it mean? Will they be downloaded automatically from the repository?
When no version is specified it means it worked with the package version which was in the repository at the same time as that package was.
It will install the current version of that package downloading it if needed.
Do I have a misaligned situation?
Yes you have a partial update.
You could build mariadb 10.3.12 against the current arch packages, downgrade arch to a date that version was in the repositories.
Run mariadb 10.3.12 in a container or virtual machine or use a separate distribution for development.
Last edited by loqs (2020-02-29 13:10:26)
Offline
When no version is specified it means it worked with the package version which was in the repository at the same time as that package was.
It will install the current version of that package downloading it if needed.
in the future, also these packages could be a problem.
Yes you have a partial update.
You could build mariadb 10.3.12 against the current arch packages, downgrade arch to a date that version was in the repositories.
Run mariadb 10.3.12 in a container or virtual machine or use a separate distribution for development.
this is very interesting. I have to try.
I don't want to use VMs, too heavy for me.
Docker could be a solution.
I don't want to change distro. I don't want to update every 6 months.
The update always breaks something and therefore, format and reinstall the system.
I have been using archlinux for 2 years and nothing has broken.
Offline
The usual solution to this is to either:
- figure out some way that you can use the newest version of mariadb when developing your software (your work may be grateful when the time comes to upgrade your work environment and there is someone who actually tested that it works on newer mariadb versions)
- create a copy of the old mariadb PKGBUILD, name it mariadb10.3, and compile it so that it can be co-installed next to the repository version, and you can link to and use the old version you need; optionally upload it to the AUR if you think other people might need the same (people do this for older python releases, for older gcc or clang versions, for every single php version since that can be quite finicky...)
- if you do not have any packages which depend on mariadb{,-libs,-client}, then you don't care which version you have installed, as long as mariadb itself works. So you could just fork the old PKGBUILD, recompile it against the current versions of its dependencies, and use your custom version
In the second and third scenarios, you are responsible for making sure the package works, and rebuilding it if/when its dependencies bump their sonames.
Last edited by eschwartz (2020-03-01 02:48:28)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
The usual solution to this is to either:
- figure out some way that you can use the newest version of mariadb when developing your software (your work may be grateful when the time comes to upgrade your work environment and there is someone who actually tested that it works on newer mariadb versions)
- create a copy of the old mariadb PKGBUILD, name it mariadb10.3, and compile it so that it can be co-installed next to the repository version, and you can link to and use the old version you need; optionally upload it to the AUR if you think other people might need the same (people do this for older python releases, for older gcc or clang versions, for every single php version since that can be quite finicky...)
- if you do not have any packages which depend on mariadb{,-libs,-client}, then you don't care which version you have installed, as long as mariadb itself works. So you could just fork the old PKGBUILD, recompile it against the current versions of its dependencies, and use your custom version
In the second and third scenarios, you are responsible for making sure the package works, and rebuilding it if/when its dependencies bump their sonames.
this may work until the other packages are updated. If packages were updated
inetutils
libsystemd
libxml2
ZSTDwith a new version no longer compatible with mariadb 10.3.12?
I think the best way is to put all your development environment in a docker container and it will always work.
I have already done this and it is working fine.
I thought of other ways to do it but I think they are unclean solutions
Offline
- create a copy of the old mariadb PKGBUILD, name it mariadb10.3, and compile it so that it can be co-installed next to the repository version, and you can link to and use the old version you need; optionally upload it to the AUR if you think other people might need the same (people do this for older python releases, for older gcc or clang versions, for every single php version since that can be quite finicky...)
not only this, systemd services should also be managed ....
Installing mariadb 10.3 would override mariadb 10.4 systemd services:
/usr/lib/systemd/system/mariadb.service
/usr/lib/systemd/system/mariadb@.servicetherefore it would be necessary to create services with another name to separate the applications.
it could be done, but it becomes a long and heavy operation.
For me, better isolate the development environment.
Offline
it seems clear what needs to be done. I close the thread.
Mark as solved
Offline
eschwartz wrote:In the second and third scenarios, you are responsible for making sure the package works, and rebuilding it if/when its dependencies bump their sonames.
this may work until the other packages are updated. If packages were updated
inetutils libsystemd libxml2 ZSTDwith a new version no longer compatible with mariadb 10.3.12?
I think the best way is to put all your development environment in a docker container and it will always work.
I have already done this and it is working fine.
I thought of other ways to do it but I think they are unclean solutions
Yes, that's why I said you're responsible for rebuilding it by entering the directory of your PKGBUILD, modifying the pkgver variable to increment the integer count up by one, and re-running makepkg.
P.S. I would not worry about these changing any time soon:
zstd -> libzstd.so.1
systemd-libs -> libsystemd.so.0
libxml2 -> libxml2.so.2
As for inetutils, that is a collection of command-line programs, which never cause you to need to rebuild anything, and I very much doubt these command-line tools will break their documented command-line API any time soon.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Pages: 1