From owner-freebsd-current@FreeBSD.ORG Thu Aug 23 16:26:27 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 87DF5106566C for ; Thu, 23 Aug 2012 16:26:27 +0000 (UTC) (envelope-from jeffreybouquet@yahoo.com) Received: from nm26-vm0.bullet.mail.sp2.yahoo.com (nm26-vm0.bullet.mail.sp2.yahoo.com [98.139.91.230]) by mx1.freebsd.org (Postfix) with SMTP id 2F65B8FC15 for ; Thu, 23 Aug 2012 16:26:27 +0000 (UTC) Received: from [72.30.22.77] by nm26.bullet.mail.sp2.yahoo.com with NNFMP; 23 Aug 2012 16:26:26 -0000 Received: from [72.30.22.33] by tm11.bullet.mail.sp2.yahoo.com with NNFMP; 23 Aug 2012 16:26:26 -0000 Received: from [127.0.0.1] by omp1061.mail.sp2.yahoo.com with NNFMP; 23 Aug 2012 16:26:26 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 755567.4459.bm@omp1061.mail.sp2.yahoo.com Received: (qmail 42019 invoked by uid 60001); 23 Aug 2012 16:26:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1345739186; bh=3DspHp/3DlXoy1WBGV5xE3C7i7312TGFXPQFrnJjFDs=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=bV0ZRbQ4tPrKgnJz98gIBYvrb+5kgX1dJsWh9oqrZnGRvOO9ojdg3sEj41EXy/uy6m/uwtXx+8URZI+9olb8La8X3MOzmQrGaNtbeDxamVBBNVnzPDsghC9FgTDNXrKae6MrKMUC7tlfD3Zmru7Dwo5VzSSddcpXMUri1tWK8lI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=J/kcuFJvYHymiOtNwKcpYFlO90tcuhTQoHn3BvU+rFBW3ZYLB35A1kS4hV49YSqr3Mwt8y1/yWRCIQDzvF8Pco1w5PTVWqAqzg1r75il//9+q5uOZcw3gjAE/cMXPOjHn1/q9cueVCU7tYPeTnC1JQ5V7X1J/W4HIZ/lWqqRNFY=; X-YMail-OSG: B0yPEJ0VM1nHYeMpq_swFO1_7bUPzSMHLOsfllO0SXHgrtW XcrnrsXw9CK6fShCA3fBqUKPkKlLuNer5Nxn7tPLcAldEVG3ATTQK4tGfBGc eP1NeNePCjoDIxLTaYNrHYFEHsXrRBHAGnR096ZL2Rn9NkyuQseg1WmL9GBn EhsycyBXK0fVbDRCPzUacwPU2.Br1z9RV3R1CsjIN49O2BtWpBJq3FlHXw1R o2gJSFovlwINsGmeipb7FHR3eaxPJAa_JGiFJhTVHm9ja3NQ4Gy313pA7gEd xTFKYyf.wIluJHLItxI9WUJqzqU5Uc3_I97WKTVdmgEgzjItrQj8C76vfetw 0K4NuYhQ2rM3CZgXyG1ptX5AmJCulM1wYfJjAWzt6nxufIG_jYGDpfxl0xxo SIs0Vd344YriFJpNLdg.yddwuCIFxyKZu0vyIpD8VHWN7f4AbJtqS4Urba7f iH0wcr7iW0jAf5EEfitYtfTKf6NLwEXi2nv9k5QUY4r34mKKoC3uNayey.f9 Oy10E6BlTBe1ge5sXfsRwTSq8sjQE4.dNOnEXEPbqbt4FKGDPot57kGhumfu w Received: from [66.92.43.99] by web111307.mail.gq1.yahoo.com via HTTP; Thu, 23 Aug 2012 09:26:26 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1345739186.30848.YahooMailClassic@web111307.mail.gq1.yahoo.com> Date: Thu, 23 Aug 2012 09:26:26 -0700 (PDT) From: Jeffrey Bouquet To: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 23 Aug 2012 16:34:44 +0000 Cc: freebsd-current@freebsd.org Subject: pkgng default schedule... registering a few reasons for rethinking the final implementation... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 16:26:27 -0000 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) ... I suspect stalling of successful frontends to bsd (pc-bsd, ghostbsd, pfsense..) due to less-reliability, more-possibility of bugs.. ... 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... ... 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. ... 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 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 ............. 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...