Re: Release process (was Re: DarwinPorts 1.3.1)

Le 3 août 06 à 16:03, Ronald Oussoren a écrit :

>
> On Aug 3, 2006, at 6:15 AM, Paul Guyot wrote:
>
>>
>> Library injection gives enough granularity to be able to  
>> independently:
>> - detect what the package refers to
>> - prevent the package from doing dirty things
>> - prevent the package from referring to things
>>
>> While chroot doesn't provide this granularity.
>>
>> I maintain that the third item isn't required at all. It changes  
>> some details, but a robust package generation tool can only be  
>> based on the first two items.
>>
>> On the box building packages, it's perfectly fine if a port A  
>> refers to port B while the dependency isn't declared in the  
>> portfile. We only need to add the dependency rule because the box  
>> installing packages should install port B before installing port  
>> A. Preventing port A to detect port B either reduces the features  
>> of the package of port A (it could take advantage of port B) or  
>> will make it fail (if a node fails in the dependency graph, the  
>> connected nodes cannot be built either).
>
> Doesn't that mean that without the 3th item the contents of the  
> package for A would vary on whether or not port B happens to be  
> installed on the package build system? That is IMHO a bad thing,  
> this entire discussion seems to be about getting reproducable  
> builds and not having the 3th item seems to defeat that.

The 3rd item affects reproductability but not the way you seem to  
imply, on the contrary. Reproductability means that the third item  
should not be implemented.

Let's consider the following three concrete cases:
Case #1: All binaries are built on a given box with trace mode, users  
don't compile their own ports (or they do with trace mode).
Case #2: Some binaries are built on a given box with trace mode,  
users can also compile their own ports (without trace mode).
Case #3: Tests are run on a given box with trace mode. Users compile  
their own ports (without trace mode).

The path towards #1 (if desirable) obviously goes throuh #2 and #3.

In case #1, the 3rd item doesn't change much, especially if all ports  
are not buggy (which they are not). If the 3rd item is implemented,  
packages will ever only depend on what they declare they depend to.  
Not declaring a dependency can actually become intentional, for  
example to provide a no-jpeg variant of a software (although this  
increases the difficulty to maintain the port). If the 3rd item isn't  
implemented, packages will be able to refer to as many ports as  
possible (since quickly the box will have a large set of non- 
conflicting ports installed) and the dependency rules will be updated  
whenever a reference is detected.

There are additional slight differences between both cases. For  
example, not implementing the 3rd item will reveal conflicts between  
ports (imagine a configure program that test if something is not  
there and fail if it is). We can also imagine cases where the 3rd  
item is more desirable (imagine a configure program that iterates  
over many other ports it actually doesn't need to depend on).

In case #2 and #3, because users can compile their own ports without  
the trace mode, the third item should not be implemented in order to  
reproduce the installation of users as much as possible. We want to  
catch and update dependencies that might appear on user installations.

The way I see it is that we're not going to see case #1 any time  
soon, especially considering the combinatorial explosion of the  
number of binary packages (we support two MacOS X major releases, two  
processor architectures plus the variants and the dependency graph).  
And the third item slows down the testing process (the dependency  
graph walk will end at the first undeclared required dependency).

Paul
-- 
Ministre ultraplénipotentiaire en disponibilité.
Mobile. Sans baignoire fixe.
http://www.kallisys.com/
http://www-poleia.lip6.fr/~guyot/