Re: ports and PBIs

On 4/10/10 12:07 PM, Tim Kientzle wrote:
> 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

yeah that's more or less what we were thinking..
hardlinks allow you to garbage collect when the last pbi that needs 
something is replaced/removed.
It's also to handle the cases where library A wants library B.  you 
don't want library A in the shared place looking for B back in the 
original PBI directory so there may need to be some patching up.

>
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"