Re: pkgng default schedule... registering a few reasons for rethinking the final implementation...

From: Julien Laffaye <jlaffaye_at_freebsd.org>
Date: Thu, 23 Aug 2012 20:29:53 +0200
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
Received on Thu Aug 23 2012 - 16:29:59 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:30 UTC