FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 05-19-2011, 02:58 PM
Florian Pritz
 
Default 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
 
Old 05-27-2011, 12:22 AM
Dan McGee
 
Default Status of sodeps?

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
 
Old 05-27-2011, 11:31 AM
Florian Pritz
 
Default Status of sodeps?

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
 
Old 05-27-2011, 12:04 PM
Xavier
 
Default Status of sodeps?

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.
 
Old 06-01-2011, 06:33 PM
Dan McGee
 
Default Status of sodeps?

On Fri, May 27, 2011 at 7:04 AM, Xavier <chantry.xavier@gmail.com> 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
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
 
Old 06-01-2011, 06:35 PM
Dan McGee
 
Default Status of sodeps?

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
 
Old 06-01-2011, 07:32 PM
Florian Pritz
 
Default Status of sodeps?

On 01.06.2011 20:33, Dan McGee wrote:
> On Fri, May 27, 2011 at 7:04 AM, Xavier <chantry.xavier@gmail.com> 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
> 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
 
Old 06-01-2011, 11:55 PM
Allan McRae
 
Default Status of sodeps?

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
 
Old 06-02-2011, 12:42 AM
Dan McGee
 
Default Status of sodeps?

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
 
Old 06-04-2011, 03:06 PM
Allan McRae
 
Default Status of sodeps?

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
 

Thread Tools




All times are GMT. The time now is 12:49 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org