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

Go Back   Linux Archive > ArchLinux > ArchLinux Pacman Development

 
 
LinkBack Thread Tools
 
Old 01-31-2011, 06:15 PM
Florian Pritz
 
Default 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
 
Old 02-01-2011, 01:53 AM
Dan McGee
 
Default 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
 
Old 02-01-2011, 07:06 AM
Xavier Chantry
 
Default 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 ?
 
Old 02-01-2011, 01:46 PM
Florian Pritz
 
Default 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
 

Thread Tools




All times are GMT. The time now is 06:32 AM.

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