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

[Kevin Oberman]

On Mon, Feb 3, 2014 at 7:23 PM, Jeffrey Bouquet <jeffreybouquet at yahoo.com>wrote:

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

For all of us who have scripts already in use that  take advantage of the
old pkg database, why not a tool to generate the old db from the new. All
of the data is in the new db... it only needs to be extracted and
formatted. Looks to be easy to do in Perl or Python. Could be written in C,
of course, but that seems like overkill. (And I am not volunteering to do
it as I can't make any promises on when I might get around to it.)

-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman at gmail.com