pkgng: how to upgrade a single port?

[Benjamin Lee]

On Mon, 4 Nov 2013 16:11:45 -0500, Paul Mather <paul at gromit.dlib.vt.edu> wrote:
> 
> On Nov 4, 2013, at 3:19 PM, Adrian Chadd <adrian at freebsd.org> wrote:
> 
> > Hi,
> > 
> > Just please keep in mind that when it claims the same version package
> > needs to be reinstalled, it seems to be for a good reason. Eg, the
> > base system library dependencies have changed.
> > 
> > Since there's no "stable" package snapshot, various package versions
> > get upgraded all the time. A package update to fix a security
> > vulnerability may have occured whilst its dependencies got updated, so
> > you have to upgrade the dependencies. And their dependencies. etc,
> > etc.
> 
> 
> I appreciate that, and that is why package managers have dependency solvers that can work out which packages must be updated.  But, as I pointed out below, there are also cases where not all packages need to be upgraded at once yet, ostensibly, "pkg upgrade" only supports this method of upgrading (everything en masse).  I have stumbled across this use case myself.  For example, one time there was a critical Java security update to openjdk7 but also apache-solr had updated from version 4.1 to 4.4 in our poudriere repo.  I wanted to upgrade openjdk7 but not apache-solr at that time, because I wanted to check that the software we were developing that used Solr was compatible with 4.4.  Being able just to do "pkg upgrade openjdk7" would have been the intuitive path there.  (I wasn't at that time aware of "pkg install openjdk7" to achieve the same end, so I ended up "pkg lock apache-solr" followed by "pkg upgrade" instead, which ended up not quite working 100% due to implementatio
>  n bugs in pkg lock.)

What you're referring to has nothing to do with the implementation
details of pkg(8) or any other package manager like Yum.

This is an inherent issue to rolling release distributions such as the
FreeBSD Ports collection.  As has been mentioned already, some
distributions with versioned release strategies (such as Red Hat
Enterprise Linux) freeze their package dependency graphs.  And since
upstream developers frequently require versions newer than the frozen
dependencies, they have also effectively forked every package in their
distributions (and introduced their own bugs like the infamous Red Hat
Perl bug [1]).

Anybody is welcome to fork and maintain their own ports tree and use the
same type of versioned release strategy -- large shops already do this.
Existing tools (even the older pkg_* family and tinderbox) can then be
used to perform one-off upgrades.

[1] http://www.infoworld.com/d/developer-world/bitten-the-red-hat-perl-bug-070


-- 
Benjamin Lee
http://www.b1c1l1.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20131104/d9aff168/attachment.sig>