Deterministic package building with ports

[Doug Barton]

Peter Schuller wrote:
> Hello,
> 
> I have been in a perpetual multi-year struggle to sort out package
> building in a way which is practical for me.

One thing I'm confused about here, what are your goals? You don't
mention why you need to build the packages. The answer to this might
inform the rest of the conversation.

> For the past half year or
> so I have ended up using a hacked together shell script which does
> approximately what I need, which is:
> 
>   To build deterministically as a function of
>     (a) base system
>     (b) /etc/make.conf
>     (c) /usr/local/etc/ports.conf (sysutils/portconf)

These are givens, but it never hurts to mention requirements explicitly.

>     (d) a list of specifically desired origins/packages which is manually
>         mainteined (NOT a complete list of dependencies, this is critical)

Why is not maintaining the list of dependencies critical? I'm guessing
the answer is related to the dependencies being fluid over time.

>     (e) the ports tree

>   a set of packages for later installation on another system
>   (typically the host system or other jails).

I'm assuming this last bit is the answer to my question above, which
makes me even more curious as to your comment about the dependencies.

> This has *sort* of worked, but not quite. I am fairly close now to
> have something that works, but am running into determinism issues. For
> example, the dependencies of audio/aumix is a function of what happens
> to already be built on the system. So initially when my script wants
> to build audio/aumix, it happens to be the case that no X stuff has
> been brought in yet, so 'make package-name' returns aumix-x.y.z. Later
> on when aumix is picked up as a dependency as part of building
> something else, 'make package-name' returns aumix-gtk-x.y.z. This
> causes confusion because the tool thinks the "origin"[1] audio/aumix
> has not been installed on the system.
> 
> Is it the intent of the design of ports that the behavior of packages
> be implicitly dependent on the state of installed packages?
>
> If the answer is yes, can someone suggest a practically viable that
> consistently works, method of building binary packages under the above
> conditions?

Yes, this is a feature. You could solve the problem you describe above
by building the X stuff first.

> (I know of portupgrade/portmaster of course. I have never found a tool
> that both (1) does what I want 

What you want is beyond the scope of current tools. I have a proposal
for adding this functionality to portmaster but it is a considerable
amount of work and therefore I was hoping to get some funding to support
it.

> and (2) actually works consistently.

If you wanted to list the ways that portmaster does not work
consistently in a different thread I'd be interested.


hth,

Doug

-- 

    This .signature sanitized for your protection