How problem with backward compatibility of packages in repo is solving

pkh · 2020-06-10 09:48:22

Hey,

The first one thing - I'm using Archlinux from 2017 as my main os, so I want to thank everyone for this distribution. It is really great thing

I have a question about process of upgrading packages in repository.
I'm not sure how it looks like.
For example we have a package X, and packages Y, Z, W which are using X as dependencies.
What a maintainer is doing when new version of X was created and changes are not backward compatible with older version?

As I understand, official repository is keeping only the newest version of package, so X should be upgrade to the newest version. But in this scenario Y and W will stop working and we will be have a broken packages in repo (for example we will be not able to compile them because there was changes in headers in new version of X).

The simple solution could be just upgrade Y, Z, W to the newest version of X, but it is not so simple (for example, a lot of changes in X, etc) and it can take a long time.

How this problem is solving?

Thanks

Mr.Elendig · 2020-06-10 10:00:35

Varies on a case by case basis.

teckk · 2020-06-10 19:54:05

The first one thing - I'm using Archlinux from 2017 as my main os

Are you saying that you have not updated since then?

If not then first step.

pacman -Syu

Bring everything to date. Look at the arch news first. That's too long to wait.
https://www.archlinux.org/news/

After successful update everything in the repo will work. If you need to compile something from AUR, compile it against the updated machine. If the AUR packages won't compile then they need to be updated.

https://wiki.archlinux.org/index.php/Ar … Repository
https://wiki.archlinux.org/index.php/Arch_Build_System
https://wiki.archlinux.org/index.php/PKGBUILD

Or do you mean something else?

Trilby · 2020-06-10 20:18:52

pkh wrote:

For example we have a package X, and packages Y, Z, W which are using X as dependencies.
What a maintainer is doing when new version of X was created and changes are not backward compatible with older version?

What should happen is that Y, Z, and W will be rebuilt against the new X, and all four of them will be added to the repo(s) at the exact same time. This is almost always what happpens - it has happened that all four are not added to the repos at the exact same time, but instead some of them lag by an hour or so. This sucks for anyone who happens to update during that window - but any resulting problem is fixed by updating again.

Far more rare would be some of them being added to the repo without others being rebuilt. There have been cases of this in the past, but pretty much only when one of X, Y, or W is a rarely used package and gets overlooked until someone reports it. Once reported, it gets rebuilt.

In any case, from a user's perspective, this should simply not matter. Don't do partial upgrades and you should never have to worry about any of this. It's the developers / packagers job to ensure dependency updates are appropriately coordinated. And they do a great job of it.

pkh wrote:

But in this scenario Y and W will stop working and we will be have a broken packages in repo (for example we will be not able to compile them because there was changes in headers in new version of X).

The only reason that Y or W would not be able to be built against the new X would be if Y or W are not (very) actively maintained upstream. In such cases, the update to X should be held (e.g., in [testing]) until Y and W are sorted out. It may be sorted out by contacting upstream to encourage them to patch the software for the new X. Failing that, the dev / packager could try to patch it. If all else fails, and it is unlikely that Y or W would be able to be updated, they'd be dropped from the repos. There should never be a package in the repos if all of it's depednencies are not met by repo packages - if it happens, it's a bug that should be reported.

Anyhow - it sounds like you have a specific scenario in mind. Do you think you've seen a case like what you describe? What are the problematic packages?

Xyne · 2020-06-10 23:54:57

Trilby wrote:

Anyhow - it sounds like you have a specific scenario in mind. Do you think you've seen a case like what you describe? What are the problematic packages?

I think he is asking about the hypothetical scenario of a new release of X containing non-backwards-compatible changes that will take the devs of Y, Z and W a while to integrate. Would Arch update a library that breaks multiple dependencies before upstream of the dependant packages has had time to update?

That usually occurs with a major version bump in X. When the update is not backwards-compatible and many or important packages depend on the previous version, it will often be temporarily packaged alongside the new version. E.g. if version 4 of X is bumped to 5 and breaks dependencies, version 5 may be packaged as X and version 4 may be packaged as X4, with updated dependencies ("X" -> "X4"). It may happen the other way around too, with X5 as a future-looking package and version 4 remaining as X until the others catch up.

eschwartz · 2020-06-11 02:22:21

pkh wrote:

I have a question about process of upgrading packages in repository.
I'm not sure how it looks like.
For example we have a package X, and packages Y, Z, W which are using X as dependencies.
What a maintainer is doing when new version of X was created and changes are not backward compatible with older version?
As I understand, official repository is keeping only the newest version of package, so X should be upgrade to the newest version. But in this scenario Y and W will stop working and we will be have a broken packages in repo (for example we will be not able to compile them because there was changes in headers in new version of X).
The simple solution could be just upgrade Y, Z, W to the newest version of X, but it is not so simple (for example, a lot of changes in X, etc) and it can take a long time.
How this problem is solving?
Thanks

Obviously if the packages are in the official repos, those packages must continue working. So either we backport an upstream patch to make it compile with the new version, or else we have no choice and must either hold back package X, or create a compatibility package containing the old version. The third option is to decide that we don't care about Y, Z, W and drop them to the AUR, but that rarely happens and the maintainers have to decide that on their own.

Arch Linux

#1 2020-06-10 09:48:22

How problem with backward compatibility of packages in repo is solving

#2 2020-06-10 10:00:35

Re: How problem with backward compatibility of packages in repo is solving

#3 2020-06-10 19:54:05

Re: How problem with backward compatibility of packages in repo is solving

#4 2020-06-10 20:18:52

Re: How problem with backward compatibility of packages in repo is solving

#5 2020-06-10 23:54:57

Re: How problem with backward compatibility of packages in repo is solving

#6 2020-06-11 02:22:21

Re: How problem with backward compatibility of packages in repo is solving

Board footer