acxz
commented
4 years ago hmm historically this has been a huge pain. I would prefer we do not use versioned deps, that just adds more complexity to the PKGBUILDs.
once we get binary packages out, we could just let the arch4edu pipeline take care of it, from what I understand they check for rebuilds consistently.
As for taking care of the rebuild on the AUR side, we can use the rebuild-detector to generate a list of packages for which to bump their pkgrel up.
I think a good solution could be we keep track of which deps should cause rebuilds. And then when said dep package updates/soname changes we run a script which increases the pkgrel of our packages that has that dep. As for figuring out when the dep package updates, that has to be reactionary. We can have someone monitor the dep packages or we do it once we actually encounter the issue.
phansel
When a new version for boost, poco, Qt, Python or similar is released, some packages need to be rebuilt.
There is an approach trying to solve this issue: https://github.com/maximbaz/rebuild-detector That solution has the disadvantage that we discover the need of a rebuild only when we linked our package against an old version of the library and installed a new version of the library meanwhile.
To track which version of the library our package depends on, we could use versioned dependencies in the PKGBUILDs that we adjust every time we need a rebuild. (Official Arch packages signal a rebuild by increasing the pkgrel. see https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/boost&id=41c5d32f4ff454ddfca19fcb4a8314594df453f6)
Do versioned dependencies prevent a new version of a library to be installed when we depend on the old one?
The hard part of this is to determine whether to depend on a specific version of a library or on the library in general. And whether to depend on the major, minor or patch version.