On 01.02.2011 03:53, Dan McGee wrote: > On Mon, Jan 31, 2011 at 1:15 PM, Florian Pritz > <[email protected]> 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
signature.asc
Description: OpenPGP digital signature
