[Portland] Current plan summarized

[nf2]

Ian Murdock wrote:
> On Thu, 2006-03-16 at 20:40 +0100, Kevin Krammer wrote:
>   
>> On Thursday 16 March 2006 11:12, nf2 wrote:
>>     
>>> Kevin Krammer wrote:
>>>       
>>>> On Wednesday 15 March 2006 11:47, nf2 wrote:
>>>>         
>>>>> I'm still not convinced regarding the static linking of the interface
>>>>> library. We have not discussed this thoroughly and perhaps it's too
>>>>> early to decide. I think there are two options here:
>>>>>           
>>>> Static linking has the advantage that starting an  application on a system
>>>> without "DAPI" support will not fail due to unresolved symbols.
>>>>
>>>> Of course there is always the possibility to have the API part of the
>>>> library statically linked and the IPC part dlopen'ed.
>>>>         
>>> Perhaps a "strong" package dependency would be ok. Otherwise the
>>> application developer has to deal with another fallback-case.
>>>       
>> ISVs usually don't use package dependencies at all. They either link 
>> statically or ship the shared library as well.
>> Unless it is part of some kind of standard like LSB.
>>     
>
> That's why the ultimate goal is to get Portland into the LSB, so ISVs
> can know with certainty whether the runtime support is there without
> the need for static linking or bundling the shared libraries or thinking
> about fallback scenarios etc. If it's in the LSB, ISVs can use it
> knowing it will work out of the box on LSB compliant systems,
> which means every major distro they're likely to care about today.
>   
I agree. DAPI should just be "standard". If it's not there - just 
download and install it.
> I still have this nagging feeling we're making this more
> complicated than it needs to be. What is being done in the DAPI
> library that couldn't otherwise be done with a set of
> scripts? With a script based approach, you don't have to worry
> about ABIs at all, and trust me, if there's a way to do this
> without having to worry about ABIS, you want to go that route.
>
>   
I don't really understand this "ABI-phobia". On any other operating 
system, features like the "Portland Tasks" would most certainly be 
served via a (shared) system library with a standardized API.

Read this for an earlier discussion of the ABI-problem:
http://lists.freedesktop.org/archives/portland/2005-December/000035.html

Perhaps one could criticise the philosophy behind freedesktop and 
unix/linux in general: Trying to solve too many problems with "soft 
standards" to avoid common code:

* describing directories,
* environment varables,
* IPC protocols,
* script/socket/file locations,
* config file formats

The problem with that attitude is that those "soft standards" can become 
quite complex and leave a lot of room for (mis)interpretation. 
Furthermore they are very limiting when it comes to future changes, 
because you have to keep the whole mechanism stable, instead of a 
"narrow" library interface.

Regards,

Norbert