zenobit commented 2025年10月20日 12:36:37 +02:00

Include what was in MR #19

This MR will improve:

• Compare versions and revisions
• delete old template folder (stale patches)
• sync_repos() end right away if not needed
• No longer use hashes
• Better info and debug messages
• (削除) Only one template_list yet (削除ここまで)
• create templates separate lists for all repos
• searching in all templates
• results show where was found
• in all_templates list packages on new line

Needs to be solved ?

• (削除) templates list of clean void-packages (without xtra repos) (削除ここまで) probably allready solved

• Then I will look at updates (test packages only from xtra repos?) packages in void-packages should be good

• And finally shlibs

Closes #10

# Include what was in MR #19 ### This MR will improve: - Compare versions and revisions - delete old template folder (stale patches) - sync_repos() end right away if not needed - No longer use hashes - Better info and debug messages - ~Only one template_list yet~ - create templates separate lists for all repos - searching in all templates - results show where was found - in all_templates list packages on new line Needs to be solved ? - ~templates list of clean void-packages (without xtra repos)~ probably allready solved - Then I will look at updates (test packages only from xtra repos?) packages in void-packages should be good - And finally **shlibs** Closes #10

mobinmob commented 2025年10月20日 12:49:25 +02:00

With a quick look, that seems fine :)
Let me test and hopefully merge as-is. I will comment inline if anything seems off.

With a quick look, that seems fine :) Let me test and hopefully merge as-is. I will comment inline if anything seems off.

mobinmob commented 2025年10月20日 12:55:20 +02:00

@zenobit wrote in #30 (comment):

Needs to be solved:

• templates list of clean void-packages (without xtra repos)

I will see if I can do something about that.
I believe the best course is to discourage replacement of packages that exist in the void-packages repo.
If a replacement is needed, then the template author should rename the template and use replaces.

• Then I will look at updates (test packages only from xtra repos?) packages in void-packages should be good

We should check packages only for extra repos and those that have restricted=yes in the template.

• And finally shlibs

The naive option is to append them at the end of the shlibs of the default repo on merge. The hyprland repo can be used as a test case, they specifically suggest this if I am not mistaken...

@zenobit wrote in https://codeberg.org/mobinmob/xut/pulls/30#issue-2538206: > > Needs to be solved: > > * templates list of clean void-packages (without xtra repos) I will see if I can do something about that. I believe the best course is to discourage replacement of packages that exist in the void-packages repo. If a replacement is needed, then the template author should rename the template and use `replaces`. > * Then I will look at updates (test packages only from xtra repos?) packages in void-packages should be good We should check packages only for extra repos and those that have `restricted=yes` in the template. > * And finally **shlibs** The naive option is to append them at the end of the shlibs of the default repo on merge. The hyprland repo can be used as a test case, they specifically suggest this if I am not mistaken...

zenobit commented 2025年10月20日 13:04:54 +02:00

I will see if I can do something about that. I believe the best course is to discourage replacement of packages that exist in the void-packages repo. If a replacement is needed, then the template author should rename the template and use replaces.

👍

We should check packages only for extra repos and those that have restricted=yes in the template.

As I thought

The naive option is to append them at the end of the shlibs of the default repo on merge. The hyprland repo can be used as a test case, they specifically suggest this if I am not mistaken...

That will brake everything. You can't have two version of same package with different versions in shlibs
I already made some tests, but needs to be still improved before MR...

> I will see if I can do something about that. I believe the best course is to discourage replacement of packages that exist in the void-packages repo. If a replacement is needed, then the template author should rename the template and use `replaces`. 👍 > We should check packages only for extra repos and those that have `restricted=yes` in the template. As I thought > The naive option is to append them at the end of the shlibs of the default repo on merge. The hyprland repo can be used as a test case, they specifically suggest this if I am not mistaken... That will brake everything. You can't have two version of same package with different versions in shlibs I already made some tests, but needs to be still improved before MR...

mobinmob commented 2025年10月20日 15:06:43 +02:00

Sorry @zenobit, I seen to have edited your post instead of quoting it in my reply... I partly blame my client app...

Sorry @zenobit, I seen to have edited your post instead of quoting it in my reply... I partly blame my client app...

zenobit commented 2025年10月20日 15:58:48 +02:00

Sorry @zenobit, I seen to have edited your post instead of quoting it in my reply... I partly blame my client app...

No problem
history is saved, so i recreate from it

PS: GitNex?

> Sorry @zenobit, I seen to have edited your post instead of quoting it in my reply... I partly blame my client app... No problem history is saved, so i recreate from it PS: GitNex?

zenobit commented 2025年10月20日 16:01:43 +02:00

I do not expect a lot of instances of that but yes, it is a real possibility unfortunately...

some of packages in hyprland (with shlibs) are also in Void

just pushed update to Void today

• hyprutils
• hyprpicker
• hyprwayland-scanner

>I do not expect a lot of instances of that but yes, it is a real possibility unfortunately... some of packages in hyprland (with shlibs) are also in Void just pushed update to Void today - hyprutils - hyprpicker - hyprwayland-scanner

mobinmob commented 2025年10月20日 16:30:11 +02:00

Yep, GitNex.

Yep, GitNex.

mobinmob commented 2025年10月20日 16:35:40 +02:00

@zenobit

I do not expect a lot of instances of that but yes, it is a real possibility unfortunately...

some of packages in hyprland (with shlibs) are also in Void

just pushed update to Void today

• hyprutils
• hyprpicker
• hyprwayland-scanner

Oh, nice 😉
I will also have something with conflicting shlibs (66 and the skarnet stack), but that a much lesser issue.

@zenobit >>I do not expect a lot of instances of that but yes, it is a real possibility unfortunately... > >some of packages in hyprland (with shlibs) are also in Void > >just pushed update to Void today >- hyprutils >- hyprpicker >- hyprwayland-scanner Oh, nice 😉 I will also have something with conflicting shlibs (66 and the skarnet stack), but that a much lesser issue.

mobinmob commented 2025年10月20日 16:41:00 +02:00

Is it possible to have a single PR in that instance?

Is it possible to have a single PR in that instance?

zenobit commented 2025年10月20日 16:49:10 +02:00

Is it possible to have a single PR in that instance?

You mean on GitHub to void-packages or here?

If void-packages
Should be in one PR
since hyprwayland-scanner is dependency of hyprutils and that dependency of hyperpicker
GitHub MR

> Is it possible to have a single PR in that instance? You mean on GitHub to void-packages or here? If void-packages Should be in one PR since hyprwayland-scanner is dependency of hyprutils and that dependency of hyperpicker [GitHub MR](https://github.com/void-linux/void-packages/pull/57604)

mobinmob commented 2025年10月20日 17:32:45 +02:00

I mean combine this PR with #19. I will first merge the xutconf PR though.

I mean combine this PR with #19. I will first merge the xutconf PR though.

zenobit commented 2025年10月21日 01:43:38 +02:00

I mean combine this PR with #19. I will first merge the xutconf PR though.

Good to go

> I mean combine this PR with #19. I will first merge the xutconf PR though. Good to go

mobinmob commented 2025年10月21日 06:29:22 +02:00

Merging, thanks a lot for your work and patience :)
Now I will test, test and then test some more...
The commented-out section was needed before, let's see if your much more refined approach makes it obsolete (completelly possible).

Merging, thanks a lot for your work and patience :) Now I will test, test and then test some more... The commented-out section was needed before, let's see if your much more refined approach makes it obsolete (completelly possible).