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, JulienReceived 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