Re: ports and PBIs

On Mon, May 3, 2010 at 7:33 AM, Kris Moore <kris_at_pcbsd.org> wrote:
> On 05/01/2010 00:29, James Butler wrote:
>>
>> Genuine (possibly stupid) question -in PBI land, what happens if
>> package B is, say, CUPS? Does one need versioned rc.d scripts to start
>> one or the other? Which one gets to claim port 631?
>
> That is a problem we are dealing with right now. We have to check to ensure
> that we don't already have a rc.d script for CUPS, and default to the
> pre-existing one if so. The only other option I see is that we default to
> the PBI one, but either way we can only have one copy running at a time :)

Hi Kris,
    In general though, conflicting services or applications reading /
touching files with version dependent data is going to be a difficult
run for PBI based fat packages though, correct? This was one of the
items that I brought up that was concerning in my previous questions,
but it kind of got lost in the bikeshed portion of the discussion that
I started with a few folks.
    My point is that just looking for one set of rc.d scripts might be
oversimplifying the problem statement a bit; I understand that good
applications should have an alternate configuration option at the very
least, or should be modified (via some in-place sed action or
something similar at install time) so that the default location is
${DBI_DESTDIR}/${PREFIX}/<blah>, correct? Also, for services like
cups, there could have per-application virtualized networking stacks
implemented per daemon (via vimage?) to circumvent this caveat,
correct (cues Julian for the confirmation)?
    Or are shared jail(8) environments the only real means to solve
this problem (probably not the correct nomenclature, but something
conceptually similar to a shared jail built out of links pointing to
the system binaries wherever possible and a series of shared ports
libraries wherever not possible)?
Thanks,
-Garrett