[pacman-dev] Status of sodeps?
It's been quite a while since I last brought this up so what's the current status? Older discussions and the link to my repo are here [1]. [1] https://wiki.archlinux.org/index.php/Pacman_Roadmap#sodepends -- Florian Pritz -- {flo,bluewind}@server-speed.net
On Thu, May 19, 2011 at 9:58 AM, Florian Pritz <bluewind@server-speed.net> wrote:
It's been quite a while since I last brought this up so what's the current status?
Older discussions and the link to my repo are here [1].
[1] https://wiki.archlinux.org/index.php/Pacman_Roadmap#sodepends
Sorry for the delayed response. My biggest piece of feedback that I levied before and got some positive feedback on before is doing s/so/lib/ on the naming so we can extend this in the future to non-so library formats if desired. How costly is the find_sodepends() bit, especially on packages with thousands of files (sage-mathematics, game data, etc)? Unlike soprovides this has to look at every single file. After that I am good to merge these, although I'll wait for Allan's return in case he has any final feedback. -Dan
On 27.05.2011 02:22, Dan McGee wrote:
On Thu, May 19, 2011 at 9:58 AM, Florian Pritz <bluewind@server-speed.net> wrote:
It's been quite a while since I last brought this up so what's the current status?
Older discussions and the link to my repo are here [1].
[1] https://wiki.archlinux.org/index.php/Pacman_Roadmap#sodepends
Sorry for the delayed response. My biggest piece of feedback that I levied before and got some positive feedback on before is doing s/so/lib/ on the naming so we can extend this in the future to non-so library formats if desired.
Fixed
How costly is the find_sodepends() bit, especially on packages with thousands of files (sage-mathematics, game data, etc)?
I've asked a few people, looked at the code used for stripping and I think it's safe to check only executable files. That cut down the time needed for sage from 5 min to 19 sec (i7-920, tempfs). I've also noticed that the stripping code uses -perm -o+x and not -executable. The manpage says -executable also checks ACLs and owner, group, other. Any reason why we don't use -executable? -- Florian Pritz -- {flo,bluewind}@server-speed.net
Florian Pritz wrote:
I've asked a few people, looked at the code used for stripping and I think it's safe to check only executable files. That cut down the time needed for sage from 5 min to 19 sec (i7-920, tempfs).
I've also noticed that the stripping code uses -perm -o+x and not -executable. The manpage says -executable also checks ACLs and owner, group, other. Any reason why we don't use -executable?
If it's not portable, we need a specific case for GNU/Linux. But we already have to do that for other tools.
Florian Pritz wrote:
I've asked a few people, looked at the code used for stripping and I think it's safe to check only executable files. That cut down the time needed for sage from 5 min to 19 sec (i7-920, tempfs).
I've also noticed that the stripping code uses -perm -o+x and not -executable. The manpage says -executable also checks ACLs and owner, group, other. Any reason why we don't use -executable?
If it's not portable, we need a specific case for GNU/Linux. But we already have to do that for other tools. If you can find it in the manpages for our current known-working
On Fri, May 27, 2011 at 7:04 AM, Xavier <chantry.xavier@gmail.com> wrote: platforms (FreeBSD, OS X, Cygwin?), then I'm fine with switching to it. Otherwise as Xavier said it might not be worth the hassle. -Dan
On 01.06.2011 20:33, Dan McGee wrote:
Florian Pritz wrote:
I've asked a few people, looked at the code used for stripping and I think it's safe to check only executable files. That cut down the time needed for sage from 5 min to 19 sec (i7-920, tempfs).
I've also noticed that the stripping code uses -perm -o+x and not -executable. The manpage says -executable also checks ACLs and owner, group, other. Any reason why we don't use -executable?
If it's not portable, we need a specific case for GNU/Linux. But we already have to do that for other tools. If you can find it in the manpages for our current known-working
On Fri, May 27, 2011 at 7:04 AM, Xavier <chantry.xavier@gmail.com> wrote: platforms (FreeBSD, OS X, Cygwin?), then I'm fine with switching to it. Otherwise as Xavier said it might not be worth the hassle.
Ok, I'll just use u+x and not waste our time. I also noticed the strip code actually uses u+w so this shouldn't be changed anyway (.a files are 644 only). -- Florian Pritz -- {flo,bluewind}@server-speed.net
On Fri, May 27, 2011 at 6:31 AM, Florian Pritz <bluewind@server-speed.net> wrote:
On 27.05.2011 02:22, Dan McGee wrote:
On Thu, May 19, 2011 at 9:58 AM, Florian Pritz <bluewind@server-speed.net> wrote:
It's been quite a while since I last brought this up so what's the current status?
Older discussions and the link to my repo are here [1].
[1] https://wiki.archlinux.org/index.php/Pacman_Roadmap#sodepends
Sorry for the delayed response. My biggest piece of feedback that I levied before and got some positive feedback on before is doing s/so/lib/ on the naming so we can extend this in the future to non-so library formats if desired.
Fixed
How costly is the find_sodepends() bit, especially on packages with thousands of files (sage-mathematics, game data, etc)?
I've asked a few people, looked at the code used for stripping and I think it's safe to check only executable files. That cut down the time needed for sage from 5 min to 19 sec (i7-920, tempfs).
I've also noticed that the stripping code uses -perm -o+x and not -executable. The manpage says -executable also checks ACLs and owner, group, other. Any reason why we don't use -executable?
Allan- do you have any objections with this branch now that my concerns have been addressed? Otherwise merging this should happen in order to get some more testers. -Dan
On 02/06/11 04:35, Dan McGee wrote:
Allan- do you have any objections with this branch now that my concerns have been addressed? Otherwise merging this should happen in order to get some more testers.
Can you give me a day or two to reply fully to this. I have a couple of thoughts (which will probably result in very little change but I feel need clarified first), but it is taking me a while to get them all together at the moment. Allan
On Wednesday, June 1, 2011, Allan McRae <allan@archlinux.org> wrote:
On 02/06/11 04:35, Dan McGee wrote:
Allan- do you have any objections with this branch now that my concerns have been addressed? Otherwise merging this should happen in order to get some more testers.
Can you give me a day or two to reply fully to this. I have a couple of thoughts (which will probably result in very little change but I feel need clarified first), but it is taking me a while to get them all together at the moment.
Definitely. I'll tell you what, why don't I just leave this up to you to merge? When you do I'll know it's good to pull. -Dan
The current implementation seems fine and I would say ready to merge. I will probably make some minor changes on the merge, but mostly cosmetic stuff. However, I have one final query: Do we need some way to disable this? Is it possible that a package will have a name in the form "foo.so" that would cause an issue here? Note that is a perfectly valid package name. I find such a package name unlikely but think about if support for other library types gets added in the future then we could get potential conflicts. OSX and Windows library names are unlikely, but foo.library is a shared library in Amiga OS and a more reasonable pkgname... So options are: 1) we ignore that possibility until a real world case shows up 2) we provide a way to disable this feature 3) we move to using libprovides=() and libdepends=() arrays I am happy following #1 for the current time as I think I am probably being too wary here, but would like opinions from others on this. Finally, none of this has been documented in the man pages. Even some draft documentation that can be edited would be very helpful. Allan
On Sat, Jun 4, 2011 at 10:06 AM, Allan McRae <allan@archlinux.org> wrote:
The current implementation seems fine and I would say ready to merge. I will probably make some minor changes on the merge, but mostly cosmetic stuff.
However, I have one final query: Do we need some way to disable this?
Is it possible that a package will have a name in the form "foo.so" that would cause an issue here? Note that is a perfectly valid package name. I find such a package name unlikely but think about if support for other library types gets added in the future then we could get potential conflicts. OSX and Windows library names are unlikely, but foo.library is a shared library in Amiga OS and a more reasonable pkgname...
So options are: 1) we ignore that possibility until a real world case shows up 2) we provide a way to disable this feature 3) we move to using libprovides=() and libdepends=() arrays
I am happy following #1 for the current time as I think I am probably being too wary here, but would like opinions from others on this. 1 is fine to me at the moment, only because I think we don't need to worry yet and an easy way to disable this is add an options array value of !libdepends or something like that. Either way the decisions we are making now don't seem to be prohibiting such an addition in the future.
Finally, none of this has been documented in the man pages. Even some draft documentation that can be edited would be very helpful. Agreed, without documentation this can't really get merged and be useful to most people.
-Dan
Signed-off-by: Florian Pritz <bluewind@xinu.at> --- doc/PKGBUILD.5.txt | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/doc/PKGBUILD.5.txt b/doc/PKGBUILD.5.txt index c0fa594..b9b7855 100644 --- a/doc/PKGBUILD.5.txt +++ b/doc/PKGBUILD.5.txt @@ -150,6 +150,11 @@ name. The syntax is: `source=('filename::url')`. form 'name<>version', where <> is one of five comparisons: >= (greater than or equal to), <= (less than or equal to), = (equal to), > (greater than), or < (less than). ++ +If the dependency name appears to be a library (ends with .so), makepkg will +try to find a binary that depends on the library in the built package and +append the version needed by the binary. Appending the version yourself +disables auto detection. *makedepends (array)*:: An array of packages that this package depends on to build, but are not @@ -186,6 +191,10 @@ name. The syntax is: `source=('filename::url')`. dependency of other packages. Provisions involving the '>' and '<' operators are invalid as only specific versions of a package may be provided. ++ +If the provision name appears to be a library (ends with .so), makepkg will +try to find the library in the built package and append the correct +version. Appending the version yourself disables auto detection. *replaces (array)*:: An array of packages that this package should replace, and can be used -- 1.7.5.4
participants (5)
-
Allan McRae
-
Dan McGee
-
Florian Pritz
-
Florian Pritz
-
Xavier