[FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools

[Jeffrey Bouquet]

My first post that quotes good:  Thunderbird rather than the webmail...
[As this one is about to be send, I see that it is a restate/duplicate 
of the one
lost in a webmail glitch ... so apologies...]




On 02/03/14 14:38, Matthew Seaman wrote:
> On 03/02/2014 21:24, Julian H. Stacey wrote:
>>> be beneficial in a very short amount of time.  Even if you prefer to
>>> compile from source,
>> I use source, rarely if ever use packages, (except pkg_delete
>> to remove old broken dependencies). No opinion which scrips are better.
>>
>>
>>> you will still reap the benefits of the modern
>>> packaging system.
>> In 10.0 FreeBSD `reaped the benefit` of a default new horrible
>> registry that smells like Microsoft with quasi binary local.sqlite
>> needing special tools.  (Yes I know there's an export function.)
>>
>> For 2 decade we've poured scorn on Microsoft & its opaque easily
>> damaged hard to access registry, & lauded how with FreeBSD we can
>> examine & manipulate & repair our text based equivalent with any
>> number of personal choice text tools, & now FreeSBD is burdened by
>> this horrible Microsoft style registry.
> You're being absurd.  local.sqlite is nothing like the Microsoft
> registry[*].  It's a database of all the files etc. that are managed
> through the ports system.  No more, no less.
... our TEXT based ...

/# find /var/db/pkg -type d -name "p5*" | xargs -J % find -type f -name 
"+CONTENTS" -exec grep -H "5.12" {} \; | grep pm | gtr -s \/ "\n" | grep 
p5 | sort | uniq | xargs -J % portmaster -d -B -P -i -g % && yell || yell

That pipe, corrected ( the working version includes an incrementing | 
head -NN |  thru hundreds of p5 upgrades,  15-25  at a time,
so easy completion of the upgrade  with
only a repeat with the up arrow and a minor edit ,)  handily upgraded a 
/perl5/ subdirectory to
the default on several installs.

>
> All we have done is replace an unreliable collection of text files --
> hard to keep consistent, impossible to update in an atomic fashion and
> woefully pessimal for certain quite legitimate queries
A subset of the above pipe?


> -- with a RDBMS,
Which a user may be expected to learn

> which quite neatly disposes of those problems.  No, it isn't ascii text
> which you can grep through.
That here is a source of dismay... less creativity in pipes etc...


>    It's a set of relational tables, which you
> can query using SQL.
That here is also a lessening of the fun.

>   And that is a deal more powerful in many ways than
> grep, but not so familiar to most; so we've provided a scripting
> interface in the form pf pkg-query(8).

> Do you complain because ZFS doesn't have it's configuration data in some
> ascii text files?  How about procstat(8)? Or ld.so(1)/ldconfig(8)?

> Truth is, unix has always adopted a pragmatic approach to system data
> and stored it in whatever form would be most effective.  In our case,
> we're pretty clear that a relational database is streaks ahead of a
> directory tree full of text files.
For those reluctant to switch over, maybe a concurrent

/usr/ports/ports-mgmt/pkg_legacy_tools

Maybe even concurrent installs [both package systems, ] , if they are 
both tweaked to be co-existable, and each in
parallel improved over time.  What if an urgent upgrade to a server 
failed in one method, the
other could "env -i" in , this one "env -i " out, and the upgrade 
proceed apace.
Or a command to test which method would work best of on a specific 
upgrade, and that pkg system default (the
other backup) until the next "switchover"

Can't do that in ".... [ insert other favorite operating system here ]... "





>
> 	Cheers,
>
> 	Matthew

J. Bouquet