Re: [RFC] sorted common/shlibs to avoid merge/rebase conflicts

[Duncaen <Duncaen@users.noreply.github.com>]

[-- Attachment #1: Type: text/plain, Size: 1815 bytes --]

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/29965#issuecomment-813124670

Comment:
> > This is a better lint step (looking for duplicates) than failing on an unsorted list.
> 
> Is it easy to decide when a duplicate soname is ok or not?

If the package name is the same and it is the same as one of the edited templates or its sub packages could be a good first heuristic.
I don't think PRs should lint for things that are not related to the current package.

> > If someone forgets to sort it then we have 10 PRs all trying to reorder it,
> 
> Could we have a lint step checking that the file is sorted?

The problem is the lint step, forcing more things into the lint, especially things that don't belong to the PR in question just makes the changes larger and does not really help anyone.

> > affecting more lines than just adding a new soname in a random position instead of the end to avoid merge conflicts for newly added libraries.
> 
> Is there a policy about that? I understood sonames had to be placed at (near) the end of the file.

No, could be a "tip" instead of a policy, as it "might" reduce the work of the contributor, but it is not required. 

> The real pain for me was the experience of working with the branch in #29997, which has 7 commits for different packages which add sonames, and any rebase/editing of previous patches would cause a lot of pain. Of course, all this pain would mostly go away if I were to place each soname in a different random place in the file...

Right, its a good tip to mention, and people are doing it. Requiring a sorted file through a lint step is one work around with the mentioned downsides, randomly placing the additions is a simple workaround without any real downsides IMHO.