Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule

From: Kevin Oberman <kob6558_at_gmail.com>
Date: Sun, 15 Jul 2012 13:46:31 -0700
On Sat, Jul 14, 2012 at 4:28 PM, Jason Helfman <jgh_at_freebsd.org> wrote:
> On Fri, Jul 13, 2012 at 1:41 PM, Peter Wemm <peter_at_wemm.org> wrote:
>
>> On Fri, Jul 13, 2012 at 5:14 AM, Fbsd8 <fbsd8_at_a1poweruser.com> wrote:
>> > What I want to know is this new pkg system going to remove the
>> requirement
>> > of having the complete ports tree on my system?
>> >
>> > What I am looking for in an port system, is to install a port and any
>> files
>> > needed for the parent port and its dependents to automatically be
>> > downloaded. So in the end my system ports tree only contain the files
>> used
>> > to install the ports I use and their dependents.
>>
>> That is precisely what pkgng is for.
>>
>> At the risk of over-simplifying:
>> * Generally eliminate the need for having /usr/ports installed for end
>> user consumers of freebsd if you have no desire to compile ports with
>> custom options.
>> * Generally eliminate the need for layers over the top of pkg* like
>> portupgrade/portmaster/portmanager for those people.
>> * Play nicely with people who *are* building some (or all) of their
>> packages from /usr/ports.
>> * Provide enough look and feel compatibility with the old pkg_* tools
>> so people will feel enough at home.
>> * Assimilate an existing pkg_* machine.
>> * Store complete metadata so that going foward we have much better
>> support for package sets - eg: package repositories with custom
>> options that play nicely with official packages.
>> * Be extensible so that we can add to it as we go forward.
>>
>> In the new world order, things like portupgrade and portmanager tend
>> to be used to manage interactions between personally build ports from
>> /usr/ports and external binary packages.  If you continue to build
>> from /usr/ports, the only thing that changes is bsd.port.mk uses a
>> different command to register a package and you still use
>> portupgrade/portmaster/whatever to orchestrate your personal package
>> rebuilding.  (Well, portmaster does if you apply the simple patch to
>> it).
>>
>> pkg-1.0 is primarily an infrastructure change.   Instead of metadata
>> being stored in discrete +FOO and +BAR files in a .tgz file, it is
>> stored in a structured, extensible file.  Instead of an incomplete set
>> of metadata being stored in /var/db/pkg/* and having to be augmented
>> by reaching over to /usr/ports/*, a full set of data is stored in a
>> .sqlite file.  Instead of version numbers being baked into the package
>> name as an ascii string, the package system uses version numbers as
>> first class metadata.
>>
>> In reality, not much will change at the switch throwing, except that
>> of having good reason to be afraid of "pkg_add -r", you'll be able to
>> reasonably expect it's replacement (pkg install) to work.  And a bunch
>> of people who have a /usr/ports tree will suddenly wonder why they
>> even have it there at all.  It becomes incredibly convenient and fast
>> to use packages.
>>
>> --
>> Peter Wemm - peter_at_wemm.org; peter_at_FreeBSD.org; peter_at_yahoo-inc.com;
>> KI6FJV
>> "All of this is for nothing if we don't go to the stars" - JMS/B5
>> "If Java had true garbage collection, most programs would delete
>> themselves upon execution." -- Robert Sewell
>>
>>
> I am by no means speaking for the pkgng direction, goal or for portmgr, but
> I thought that
> this thread message spoke to the goal pretty clearly for me.
>
> http://lists.freebsd.org/pipermail/freebsd-ports/2012-June/076395.html
>
> If this is in fact the case, I don't know if this is documented anywhere.
>
> -jgh

While I will admit to a few concerns with pkgng, to me it is a beacon
of hope for FreeBSD management in my organization. It is mostly Linux
with a mostly Linux knowledgeable management team. There has been a
major ($$$) commitment to the use of cfengine-nova (the commercial
version of cfengine) for management and the package system on FreeBSD
is a major obstacle to getting FreeBSD systems moved to automatic
management which is badly needed.

>From all that I have read and played with, pkgng MAY be just the
ticket to resolving the issues we have. Without this, I foresee a time
in the not too distant future when a decision to replace all of our
FreeBSD systems with Linux will be made. While I feel that this
transition will be both expensive and painful as much of our critical
infrastructure is FreeBSD based, the cost of not having these systems
maintained in an automated manner is just too high and I had been
developing my own system to attempt to deal with it.

Once I started looking at pkgng, I saw a bright light at the end of
the tunnel and, while still not ready for prime time, it looks very
close to meeting my requirements.
-- 
R. Kevin Oberman, Network Engineer
E-mail: kob6558_at_gmail.com
Received on Sun Jul 15 2012 - 18:46:33 UTC

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