Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   ArchLinux Pacman Development (http://www.linux-archive.org/archlinux-pacman-development/)
-   -   sodeps: makepkg patches (http://www.linux-archive.org/archlinux-pacman-development/483537-sodeps-makepkg-patches.html)

Florian Pritz 01-31-2011 06:15 PM

sodeps: makepkg patches
 
The -d/-dd patches are in master now so I'll start a new thread
for the makepkg patches only.

I've tested them with readline and they work fine.

The final PKGINFO contains entries like these:
depend = libc.so=6-64
provides = libreadline.so=6-64

Git repo is here http://git.server-speed.net/users/flo/pacman/?h=sodeps

Dan McGee 02-01-2011 01:53 AM

sodeps: makepkg patches
 
On Mon, Jan 31, 2011 at 1:15 PM, Florian Pritz
<bluewind@server-speed.net> wrote:
> The -d/-dd patches are in master now so I'll start a new thread
> for the makepkg patches only.
>
> I've tested them with readline and they work fine.
>
> The final PKGINFO contains entries like these:
> depend = libc.so=6-64
> provides = libreadline.so=6-64
>
> Git repo is here http://git.server-speed.net/users/flo/pacman/?h=sodeps

So... we still haven't looked at any cross-compatibility with this.
Things that are tied heavily to specific implementation details have
bitten us before; see makepkg VCS integration.

Here is a non-so case that we need to at least think about how we might handle:
http://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryDesignGuidelines.html#//apple_ref/doc/uid/TP40002013-SW23

"so" is nowhere to be found in there, so my first thought on this
whole thing is to at least name this generically so we can extend it
now and/or in the future. Can we start calling it
libdepends/libprovides?

I have the feeling this has been hashed/rehashed/blended before, but
why aren't we just doing something like:

provides=('myenv')
libprovides=('libx.so' 'liby.so')

To me, this seems a lot clearer and alleviates the black magic
concerns of changing depends/provides arrays on the fly.

-Dan

Xavier Chantry 02-01-2011 07:06 AM

sodeps: makepkg patches
 
On Tue, Feb 1, 2011 at 3:53 AM, Dan McGee <dpmcgee@gmail.com> wrote:
>
> I have the feeling this has been hashed/rehashed/blended before, but
> why aren't we just doing something like:
>
> * *provides=('myenv')
> * *libprovides=('libx.so' 'liby.so')
>
> To me, this seems a lot clearer and alleviates the black magic
> concerns of changing depends/provides arrays on the fly.
>

I got confused by 'myenv', its supposed to be a normal provision like 'cron' ?

Anyway libprovides sounds fine to me, but the question is where do we
propagate this distinction, because there is no difference for pacman.
Should there also be a libprovides in PKGINFO and %LIBPROVIDES% in db,
and pacman will just read these two and merge them with provides ?
Or can they both be merged at the PKGINFO level ?

Florian Pritz 02-01-2011 01:46 PM

sodeps: makepkg patches
 
On 01.02.2011 03:53, Dan McGee wrote:
> On Mon, Jan 31, 2011 at 1:15 PM, Florian Pritz
> <bluewind@server-speed.net> wrote:
>> The -d/-dd patches are in master now so I'll start a new thread
>> for the makepkg patches only.
>>
>> I've tested them with readline and they work fine.
>>
>> The final PKGINFO contains entries like these:
>> depend = libc.so=6-64
>> provides = libreadline.so=6-64
>>
>> Git repo is here http://git.server-speed.net/users/flo/pacman/?h=sodeps
>
> So... we still haven't looked at any cross-compatibility with this.
> Things that are tied heavily to specific implementation details have
> bitten us before; see makepkg VCS integration.

I don't know how to that properly. Could someone give me a few hints?

> Here is a non-so case that we need to at least think about how we might handle:
> http://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryDesignGuidelines.html#//apple_ref/doc/uid/TP40002013-SW23

.dylib is a different format and I have no idea what tools are available
on OS X nor do I really care.

> "so" is nowhere to be found in there, so my first thought on this
> whole thing is to at least name this generically so we can extend it
> now and/or in the future. Can we start calling it
> libdepends/libprovides?

Since they are connected we should probably just call it libdepends.

> I have the feeling this has been hashed/rehashed/blended before, but
> why aren't we just doing something like:
>
> provides=('myenv')
> libprovides=('libx.so' 'liby.so')
>
> To me, this seems a lot clearer and alleviates the black magic
> concerns of changing depends/provides arrays on the fly.

Allan said he preferred a single array. I think that was the only reason.

Also using the depends array allows makepkg to check if the needed
libraries are installed.

--
Florian Pritz -- {flo,bluewind}@server-speed.net


All times are GMT. The time now is 01:18 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.