Re: ports and PBIs

Garrett Cooper wrote:
> If I'm understanding you correctly you're saying it's an issue when I do:
> 
> pkg_add A B C
> 
> # 1 year passes
> 
> pkg_add D
> 
> # D depends on A, B, C, of different revisions. pkg_add barfs because
> it can't find the applications, etc.
> 
> This is something that's been hashed over a number of times (a few of
> which I've participated in in #bsdports). There needs to be a simple
> update command which will handle the action of upgrading packages,
> because there isn't a proper command that will do so today.

I'm not convinced that the "simple update command" you
mention is actually feasible, much less desirable.
(If I want to try out the new Firefox, why does that
imply that my year-old Gimp has to be upgraded?)

As for feasibility, here's the easy problem:
    A2.7 requires B3.6
      ... one year passes ...
    A4.8 now requires B7.2
But A4.8 is incompatible with B3.6 and A2.7 is
incompatible with B7.2.  So neither A nor B
can be updated separately without breaking the system.

Here's the hard problem:
    A2.7 requires B3.6
      ... one year passes ...
    I want to install C1.0 which requires B7.2
    but there hasn't been a new release of A that
    works with B7.2.
So I now simply cannot have both C1.0 and A2.7
installed at the same time because they require
different versions of B.

PBI avoids both of these problems.  It may
be unsuitable for embedded systems[1], but
I see no reason we should not extend the existing
ports/packages system with additional tools that
target certain use cases, and PBI seems a good
fit for the desktop case.

Tim

[1] Actually, PBI might work just fine even for
embedded if we address the disk bloat issue.  One
approach would be to make
    /Package/Bar/libfoo-2.8.7.so
a symlink or hardlink to
    /Package/Shared/libfoo-2.8.7.so-<MD5-hash>
This gives easy sharing of identical files.
It's even easy to handle at install time:
   * Installer writes libfoo-2.8.7.so to
      /Package/Shared/libfoo-2.8.7.so-temp-<PID of installer>
   * Installer computes hash of file as it's written
   * Installer renames file (delete if rename fails with EEXIST)
   * Installer writes symlink or hardlink into /Package/Bar