WIP: feat: shlibs-development #35

zenobit commented 2025年10月21日 10:18:39 +02:00

Still work in progress
Just to show you, maybe you can help me with it

Last commit made it worst

Still work in progress Just to show you, maybe you can help me with it Last commit made it worst

mobinmob commented 2025年10月21日 10:49:37 +02:00

Are you using a specific repo to test or do you have test data somewhere? It will help to see how it breaks.
I expect shlib handling to be the most complex operation in xut. That is because you need to have a strategy and also check for everything...
I may have some time much later today.

Are you using a specific repo to test or do you have test data somewhere? It will help to see _how_ it breaks. I expect shlib handling to be the most complex operation in `xut`. That is because you need to have a strategy and also check for everything... I may have some time much later today.

zenobit commented 2025年10月21日 10:58:05 +02:00

additional_repos="https://github.com/oSoWoSo/void-hyprland
https://codeberg.org/RotaryBoot58/vpim
https://codeberg.org/mobinmob/66-voidlinux
https://github.com/dani-77/d77void-pkgs
https://codeberg.org/cereus-linux/cereus-pkgs"

Not specialy choosed for testing but trying with that

PS: https://github.com/dani-77/d77void-pkgs is big as void-packages so without it it takes much shorter time

additional_repos="https://github.com/oSoWoSo/void-hyprland https://codeberg.org/RotaryBoot58/vpim https://codeberg.org/mobinmob/66-voidlinux https://github.com/dani-77/d77void-pkgs https://codeberg.org/cereus-linux/cereus-pkgs" Not specialy choosed for testing but trying with that PS: https://github.com/dani-77/d77void-pkgs is big as void-packages so without it it takes much shorter time

zenobit commented 2025年11月13日 11:29:00 +01:00

For us good approach to implement shlibs in abyss-packages etc
Is use two files instead of one

• shlibs-remove - to remove older package mention from void-packages shlibs (should contain exact lines like are in void's shlibs)
• shlibs-add - to add new packages and changed lines (aka everything what changed)

But that doesn't solve if repo keep same (changed) shlibs as void

For us good approach to implement shlibs in abyss-packages etc Is use two files instead of one - shlibs-remove - to remove older package mention from void-packages shlibs (should contain exact lines like are in void's shlibs) - shlibs-add - to add new packages and changed lines (aka everything what changed) But that doesn't solve if repo keep same (changed) shlibs as void

mobinmob commented 2025年11月13日 11:47:01 +01:00

I believe the solution is to not try to do the impossible 🙂
Because trying to support w/e shlibs anyone can provide is a dead end. I will try to finally release this weekend, with fixed/revised template list update and maybe shlib enabled only for abyss-packages.

I believe the solution is to not try to do the impossible 🙂 Because trying to support w/e shlibs anyone can provide is a dead end. I will try to finally release this weekend, with fixed/revised template list update and maybe shlib enabled only for abyss-packages.

mobinmob commented 2026年01月12日 14:04:20 +01:00

@zenobit wrote in #35 (comment):

For us good approach to implement shlibs in abyss-packages etc Is use two files instead of one

• shlibs-remove - to remove older package mention from void-packages shlibs (should contain exact lines like are in void's shlibs)
• shlibs-add - to add new packages and changed lines (aka everything what changed)

But that doesn't solve if repo keep same (changed) shlibs as void

Unfortunatelly we do need to implement some policy...
I tried to find a suitable and sane policy that will be implemented in the abyss-packages repo and then propose to others. It is not possible to make anything sensible without third-party repo cooperation. I ended up with the following:

1. If a repos has a common/shlibs file, it should be considered.
2. In order to merge, the repo owner must provide a provide_shlibs.
3. The file should have a space- or newline-separated list of sonames.
4. Only lines that contain sonames that are in the provide_shlibs files are to be merged.

Per-entry merge should procceed if:

1. Soname is included in provide_shlibs.
2. Soname version is the same as in the common/shlibs of the $defaultRepo but package name is different.
3. Soname version is newer than in the common/shlibs of the $defaultRepo.
4. Soname does not exist in the common/shlibs of the $defaultRepo.

Pros:

• Simple policy to implement for other repos (add a single file, easy to automate).
• Simple policy to describe and document for users.
• Make extremelly clear that a repo is compatible with xut - a file in the root dir is a pretty clear indication. I am more than happy to work with other repos in order to achieve this...

Cons:

• Not exactly straightforward code (I have some, need to test...).
• Not practical to implement in anything other than awk.
• It does not account for repos that have conflicting shlibs between them - I am not sure that can be solved, at least without adding a lot of complexity.

@zenobit wrote in https://codeberg.org/mobinmob/xut/pulls/35#issuecomment-8260731: > For us good approach to implement shlibs in abyss-packages etc Is use two files instead of one > > * shlibs-remove - to remove older package mention from void-packages shlibs (should contain exact lines like are in void's shlibs) > * shlibs-add - to add new packages and changed lines (aka everything what changed) > > But that doesn't solve if repo keep same (changed) shlibs as void Unfortunatelly we do need to implement some policy... I tried to find a suitable and sane policy that will be implemented in the abyss-packages repo and then propose to others. It is not possible to make anything sensible without third-party repo cooperation. I ended up with the following: 1. If a repos has a `common/shlibs` file, it should be considered. 2. In order to merge, the repo owner must provide a `provide_shlibs`. 3. The file should have a space- or newline-separated list of **sonames**. 4. Only lines that contain sonames that are in the `provide_shlibs` files are to be merged. Per-entry merge should procceed if: 1. Soname is included in `provide_shlibs`. 2. Soname version is the same as in the common/shlibs of the $defaultRepo but package name is different. 3. Soname version is newer than in the common/shlibs of the $defaultRepo. 4. Soname does not exist in the common/shlibs of the $defaultRepo. Pros: - Simple policy to implement for other repos (add a single file, easy to automate). - Simple policy to describe and document for users. - Make extremelly clear that a repo is compatible with xut - a file in the root dir is a pretty clear indication. I am more than happy to work with other repos in order to achieve this... Cons: - Not exactly straightforward code (I have some, need to test...). - Not practical to implement in anything other than awk. - It does not account for repos that have conflicting shlibs between them - I am not sure that can be solved, at least without adding a lot of complexity.

This pull request has changes conflicting with the target branch.