From owner-freebsd-ports@FreeBSD.ORG Thu Aug 23 18:29:59 2012 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F34B106566C; Thu, 23 Aug 2012 18:29:59 +0000 (UTC) (envelope-from jlaffaye.freebsd@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 940B28FC16; Thu, 23 Aug 2012 18:29:57 +0000 (UTC) Received: by eeke52 with SMTP id e52so454300eek.13 for ; Thu, 23 Aug 2012 11:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=TllYIeSv5HJzlVroBcHkBIx5JcCJJjlugzUFlkt3PRI=; b=RM6x0r4QKyuDgJyw/UyU2uu8X9TbjE2nr4GtLEB3uU4x5oJraXTfS1iYPtAiER8nBT ZiJ7XVd/CSlfS6sw1Y1JZh6Mo/Wj3TkPz8BPtA9yuS2tYDC85C+hurjRmCCJV8113u1d rdnVOy9rtORkE2pSjkTvRpZ0yNIv/0lPdNRYl9lgGk3xSI58eO+aELFejsvd4aS0darq VZy0bcYb7fiPsZX535ZGRBDvnJaCXXFCPYCM5WUKzifoo5XxNrWBQzkJBeGuzEBSa2tt f4iWVdmuX3IvYCPqHmrxcJTyKsy6KQY7231ZA/Jq8ETBynXLmJXJUeZvfdKaccoGkcpe Kx5A== Received: by 10.14.224.4 with SMTP id w4mr3341302eep.21.1345746596813; Thu, 23 Aug 2012 11:29:56 -0700 (PDT) Received: from ?IPv6:2001:41d0:fc00:100:5cba:b160:79ac:5d0? ([2001:41d0:fc00:100:5cba:b160:79ac:5d0]) by mx.google.com with ESMTPS id u47sm23576701eeo.9.2012.08.23.11.29.54 (version=SSLv3 cipher=OTHER); Thu, 23 Aug 2012 11:29:56 -0700 (PDT) Sender: Julien Laffaye Message-ID: <503676A1.8050202@freebsd.org> Date: Thu, 23 Aug 2012 20:29:53 +0200 From: Julien Laffaye User-Agent: Thunderbird/7.0.1 MIME-Version: 1.0 To: Jeffrey Bouquet References: <1345739186.30848.YahooMailClassic@web111307.mail.gq1.yahoo.com> In-Reply-To: <1345739186.30848.YahooMailClassic@web111307.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: pkgng default schedule... registering a few reasons for rethinking the final implementation... X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 18:29:59 -0000 On 8/23/2012 6:26 PM, Jeffrey Bouquet wrote: > I am following with dread the planned implementation of the deprecation of /var/db/pkg as a package registry... I use each /var/db/pkg directory as a database into the port installation/status, using sed/grep/portmaster/portmanager/.sh scripts/find/pipes etc... to fix stuff. For instance, an upgrade py26 > py27. > cd /var/db/pkg > ls -lac | grep py26 > ls -lac | grep python > as the more simple example. > .... > With due respect to its developers and the persons who agree that > the package tools could be upgraded, the mandatory > usage of a front-end database to a file directory one > is here viewd as mutt-only-mbox, registry-and-bsod rather > than /etc/local/rc files, deprecation of sed/grep/find/locate/.sh/portmaster/portmanager as tools to fixup/upgrade the ports that are registered; > ... > I see concurrently too few tests on lower-end p2, p3 as to whether > pkg can run with lesser memory machines (routers...) (pfsense) Everyone's is welcome to help us with that! The memory usage can be decreased by using gzip over xz for (un)compression. > ... > I suspect stalling of successful frontends to bsd (pc-bsd, ghostbsd, > pfsense..) due to less-reliability, more-possibility of bugs.. If we get useful detailed bug reports, we will fix 'em! > ... > Not to mention native tab-completion not dependent upon further > customizations, > ... > Introduces complexity to running earlier versions of BSD virtualized > in later versions and vice versa... > ... > I've innumerable times made "quick work" (2 hours or so) of > cross-disk backup/fix/upgrade using /var/db/pkg where doing so > with just the pkg tools or my own scripts would take immeasurably > longer... Why ? > ... > It would deprecate searching +CONTENTS, for example, or quickly > checking the text file +REQUIRED_BY without a database frontend. > ... > Almost every reply and post have glossed over those points, referring > to the benefits of a newer package management system, again glossing > over the added memory requirements, number of .so. required, lack > of extensive testing across all hardware cpu/memory scenarios... > ... > "it will be a single tool that will do the job of all the > many port/package management scripts currently only available > in the ports system (bsdadminscripts)" for example. A single > tool, yes. But it won't do all of the edge-case jobs *not* covered > by the present pkg_ tools that can be crafted hooking into the > /var/db/pkg/ directory structure, with find for example. > "pkgng is not a replacement for portmaster or portupgrade..." That > was not my question. My concern was with the deprecation of > the latter and /var/db/pkg along with the introduction of pkgng. > ... > Each pkg_ legacy uses about 3-6 .so. afaik. > pkg uses 19. 18 :) > ... > A review of pkgng on mebsd.com, suggests replacment CLI for tasks > one might do with portmaster now. However, they are much more > arcane (%H-%M vs -g...) and thus unwelcoming... > ... > "patches for portmaster and portupgrade to use pkgng tools" > Memory requirements with both working together? > The ABI between them breaks? > ... > My concerns are more or less, why should the following *ever* be > mandatory... > "On both FBSD 10 boxes, the installation of the port security/cyrus-sasl2 got > corrupted by "install" and/or "mtree" dumping core and signalling > SIGNAL 11. Booting into multiuser mode is impossible, login core > dumps SIGNAL 11, many other daemons, too. The only way is to boot > into single user mode. > > An installation failed due to pkg(ng) was missing libarchive.so via pkgng only depends on lib in the base system. Why was libarchive.so missing? > portmaster or via core dumping install. By installing on one box, > my home box, port security/cyrus-sasl2 manually, luckily install and > mtree didn't coredump and it worked - and this procedure rescued me. > But on my lab's development box, it didn't work! " > (Continues with more equally terrible detail...) > (Freebsd-questions, august) > ... > Or my own experience, today, testing on a p4 pre-p2 memory req. > investigations. > # pkg stats > Unable to open remote database "repo". Try running 'pkg update' first. > # pkg update > Updating repository catalogue > zsh: segmentation fault pkg update Do you have useful details about this segv, like a backtrace ? > ............. > So, a kernel option (non default) to deprecate /var/db/pkg? > A further development of pkg to concurrently maintain a /var/db/pkg? > ...not implying the concurrent deprecation of the latter! > Brighter ideas? > > Thanks for reading these concerns. I am quite perturbed by the > announcement of v11 erasing the /var/db/pkg upon which I presently > use daily numerous times... > And I apologize, in advance, for typos etc. herein... > > J. Bouquet > 2004 v5... Regards, Julien