On Sunday, April 11, 2010, Tim Kientzle <kient...@freebsd.org> 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
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? -James Butler > > [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 > > _______________________________________________ > freebsd-curr...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
