pkg-1.7.0 is an order of magnitude slower than pkg-1.6.4
bapt at FreeBSD.org
Mon Apr 4 11:45:01 UTC 2016
On Mon, Apr 04, 2016 at 12:47:21PM +0200, Miroslav Lachman wrote:
> Baptiste Daroussin wrote on 04/02/2016 15:00:
> > On Sat, Apr 02, 2016 at 02:59:06PM +0200, Michael Grimm wrote:
> >> Baptiste Daroussin <bapt at FreeBSD.org> wrote:
> >>> On Sat, Apr 02, 2016 at 02:42:06PM +0200, Michael Grimm wrote:
> >>>> 26 seconds for 74 ports within a jail and pkg-1.6.4:
> >> […]
> >>>> 309 seconds for the very same 74 ports within the very same jail and pkg-1.7.0:
> >> […]
> >>>> Is this an expected slow-down? /usr/ports/UPGRADE and https://svnweb.freebsd.org/ports/head/ports-mgmt/pkg/?view=log are not indicating that behavior.
> >>>> But I might have missed something.
> >>>> Any feedback is highly appriciated, thanks, and regards,
> >>> pkg 1.7 is IO intensive that may explain.
> >> Ok, understood.
> >> JFTR: perl (24s), python27 (44s), and ruby (125s) take the longest time to reinstall.
> >>> I plan to readd some improvements on this side before 1.8
> >> Good to know, thanks for your feedback.
> > Thank you very very much for yours! very much appreciated, it helps improving
> > things!
> I already upgraded to 1.7.1. Is it possible to downgrade it back to
> 1.6.4 or are there some incompatible changes in database? (I can build
> 1.6.4 by downgrading the port in my poudriere)
No incompatibilities so you can downgrade
> And I have one question about this info from commit message:
> - if the all process operation would have an inpact of less than 1MB on
> the FS then the action is proceed with out asking the user to acknowledge it
> Does it means that pkg upgrade, pkg autoremove etc. will proceed without
> asking Y/N?
> Is this behavior configurable and can it be reverted?
The purpose of pkg 1.7.1 was to fix that regression (your quote explains the
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the freebsd-ports