You are not logged in.
Pages: 1
I hope this is the place to post for someone who is _considering_ switching to Arch who is an experienced Ubuntu/Mint user.
I am very enticed by the idea of never having to upgrade to different versions (as opposed to the many other distros I have used). Install once and always have the latest version. However, this raises concerns in my mind. Here is my list of questions related to this:
-is there a recommended procedure for successfully building & using software that is packaged with automake and configure scripts? sometimes I like to manually build open source software that I download off the internet outside of the official build process of the distro I am using. a configure script could pass and the software successfully build locally with the current set of shared object libraries installed into the arch system. But an arch update could remove libraries that were previously used to build & link the automake packaged software. So then after the arch update, all of the software that I might have built (manually) outside of the official arch build system could fail to find libraries that are required after the arch update was performed.
-when wanting to run a proprietary, paid for program binary that has certain library requirements. Is there a recommended procedure for this? Arch always uses the latest shared object libraries so this might not jive with what the binary I want to run requires. The binary might want to use an earlier shared object and I have no recourse to change this. I have to provide this using a LD_LIBRARY_PATH before I try to run the program and this means potentially that I have to somehow download the older library binaries from the arch repos and have them exist outside of the jurisdiction of the pacman package management system.
-when a shared object gets an interface change, this could affect many programs. How does arch update to using only the new library shared object when the many programs that used the shared object with the old interface are still not updated and in the repository? Does arch wait until all apps are updated before introducing the shared object with the new interface? This seems like it could take a long time while a myriad of developers fix their various applications to compile and link to the new version of the shared object.
Thanks so much for your help. I also apologize in advance if I have asked question(s) that have been answered elsewhere.
-Jay
Offline
You are expected to rebuild software not in the official repositories if ABI/API changes require it.
Use or build if not already in existance a compat package that provides the older version.
Arch using a staging repository all packages that require a rebuild are rebuilt in staging and then everything is moved out of staging.
Offline
I hope this is the place to post for someone who is _considering_ switching to Arch who is an experienced Ubuntu/Mint user.
I am very enticed by the idea of never having to upgrade to different versions (as opposed to the many other distros I have used). Install once and always have the latest version. However, this raises concerns in my mind. Here is my list of questions related to this:
-is there a recommended procedure for successfully building & using software that is packaged with automake and configure scripts? sometimes I like to manually build open source software that I download off the internet outside of the official build process of the distro I am using. a configure script could pass and the software successfully build locally with the current set of shared object libraries installed into the arch system. But an arch update could remove libraries that were previously used to build & link the automake packaged software. So then after the arch update, all of the software that I might have built (manually) outside of the official arch build system could fail to find libraries that are required after the arch update was performed.
As loqs said, you're expected to recompile them when that happens. But, there are usually AUR packages for most things, and some AUR maintainers will bump the pkgrel for soname updates. Either way, there are tools you can use to detect this -- see for example "lddd" in the devtools package.
In general, this is why official repos are great since we (the developers and trusted users) take care of this for you.
But as long as you remember to try recompiling the software as the first fix, it should not be hard to handle.
By the way: This is why it is *vital* to have a PKGBUILD to build the software, it allows you to trivially rebuild the package when you need to. It's also why Arch Linux is awesome... because PKGBUILDs are dead-simple to write, as evidenced by the fact that even simpleton's are known to write them. ![]()
(I joke, of course.
AUR users are our source of pride, and even the less expertly written packages still serve as a basis to gradually improve the entire ecosystem, and encourage improvements to percolate.)
-when wanting to run a proprietary, paid for program binary that has certain library requirements. Is there a recommended procedure for this? Arch always uses the latest shared object libraries so this might not jive with what the binary I want to run requires. The binary might want to use an earlier shared object and I have no recourse to change this. I have to provide this using a LD_LIBRARY_PATH before I try to run the program and this means potentially that I have to somehow download the older library binaries from the arch repos and have them exist outside of the jurisdiction of the pacman package management system.
Again as loqs said, the general solution is to use something like, for example, https://aur.archlinux.org/packages/ncur … mpat-libs/
Depending on the library, it is almost assuredly possible to write a PKGBUILD for foo1, which builds an old version of the software that only packages the old libraries without executables or headers or docs or whatever. And then use that directly in e.g. /usr/lib/libfoo.so.1.2.3
The old program will load this soname directly.
-when a shared object gets an interface change, this could affect many programs. How does arch update to using only the new library shared object when the many programs that used the shared object with the old interface are still not updated and in the repository? Does arch wait until all apps are updated before introducing the shared object with the new interface? This seems like it could take a long time while a myriad of developers fix their various applications to compile and link to the new version of the shared object.
This should not ever be a problem, since shared libraries should always change their soname when changing the interface in a backwards-incompatible way.
When we upgrade a software dependency, we use staging repositories to rebuild every program which uses it, and in many cases, while we discover how to fix their compilation issues -- hopefully no changes are needed, but in some cases we need to find upstream patches that may not be in a released version yet. Or write our own and submit them to upstream.
In super extreme cases, we may end up providing a "compat" package with the old version, or, if the package is not popular, even drop it to the AUR.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
ok, thanks for the detailed responses. This gets me what I need for now.
Offline
(I joke, of course.
AUR users are our source of pride, and even the less expertly written packages still serve as a basis to gradually improve the entire ecosystem, and encourage improvements to percolate.)
My experience so far:
ask_Eschwartz(my less expertly written AUR packages) -> my expertly written AUR packages
Offline
My experience so far:
ask_Eschwartz(arg ignored) -> return "you're wrong!"
![]()
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
My experience so far:
ask_Eschwartz(arg ignored) -> return "you're wrong!"
Hey, unfair!
I'm very good at telling people *why* they're wrong, and *how* to fix it. ![]()
(I have a gift for finding things to critique, what can I say...)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Pages: 1