Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 6 Feb 2014 11:13:30 -0500
From:      Randy Pratt <bsd-unix@embarqmail.com>
To:        Kevin Oberman <rkoberman@gmail.com>
Cc:        FreeBSD Ports ML <freebsd-ports@freebsd.org>
Subject:   Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
Message-ID:  <20140206111330.8df9c79e0ec1b9d2ffc9d0a1@embarqmail.com>
In-Reply-To: <CAN6yY1smkF2SdV190fE1KWKtr9FCiXBZ-08bQ=kc8vpDSnwooQ@mail.gmail.com>
References:  <201402052202.s15M2Lha059200@fire.js.berklix.net> <52F2C0C8.5010203@gmx.de> <CAN6yY1uyXNp_c4PruKM89S9g0Y0QAs02cu5Z-dx3oSg1yZC19Q@mail.gmail.com> <52F32F7C.2030601@infracaninophile.co.uk> <CAN6yY1smkF2SdV190fE1KWKtr9FCiXBZ-08bQ=kc8vpDSnwooQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 5 Feb 2014 23:26:18 -0800
Kevin Oberman <rkoberman@gmail.com> wrote:

> On Wed, Feb 5, 2014 at 10:45 PM, Matthew Seaman <
> m.seaman@infracaninophile.co.uk> wrote:
> 
> > On 05/02/2014 23:57, Kevin Oberman wrote:
> > > 1. The ports/packages system is not total crap. In fact, at the time jkh
> > > started it, it was far superior to any tool available.
> >
> > When I first encountered the ports, way back in 1998 or so, I was
> > completely mind-blown that something so fantastic could exist.  Yes, it
> > was revolutionary at the time and right where FreeBSD should be --
> > leading the rest of the world with great innovations.
>
> > However, things have changed in the last 16 years. Development of the
> > ports as a global concept has been resting on its laurels a bit, and the
> > rest of the world has caught up, and indeed overtaken.   Partly that was
> > due to the mindset of seeing binary packages as a second-class thing;
> > partly due to the old pkg_tools not providing the scope to implement
> > innovative features; partly due to pkg_tools being part of the FreeBSD
> > base, so impossible to update over reasonable timescales due to the
> > requirement to support older RELEASE branches.
> >
> > pkg(8) addresses those problems, and I hope will do so for at least the
> > next decade.
> >
> > > 5. The introduction of pkgng could have really been handled better and
> > that
> > > probably increased the negative feelings about it. It was also a bit
> > before
> > > it was really ready. It still lacks a few features I feel are quite
> > > important, but they were also missing from the old system.
> >
> > I don't think it's possible to make a change of this magnitude without
> > upsetting anyone.  We have been getting a lot of feedack on the lines of
> > 'Wow! This is great.  When can we have feature XYZ?'  to which we
> > frequently have to reply that XYZ can't be implemented without breaking
> > compatibility with pkg_tools.  Like sub-packages.
> >
> > I'd be interested to hear what features you think are missing.  We will
> > implement anything (eventually...) that there is demand for and that is
> > technically feasible, and that fits with the overall concept of what we
> > think a packaging system should do.  There's a number of ideas in the
> > github issue list already (usually tagged with 'longterm' or 'thinking')
> > and we are happy for people to add to that, or to discuss ideas -- the
> > freebsd-pkg@ list is a good place for that.
> >
> >
> One BIG one that I know is being worked is the capability to mix packages
> and ports effectively.  If you use poudriere, you can roll your own
> packages with custom options and maintain things pretty reasonably, but for
> a single system (or two), this is a bit of overkill. As things stand,  this
> is a real pain to use customized ports and packages from the standard
> FreeBSD distributions. I'm waiting with great excitement for this to
> appear, though I have no idea if it is near or far.
> -- 
> R. Kevin Oberman, Network Engineer, Retired
> E-mail: rkoberman@gmail.com
> 

My experience with mixing ports and packages dates back to 2.2.5 and
the disasters it created.  Most of the problems were created by the
ports tree and package builds not being syncronized.  I switched to
ports exclusively and have not had those problems again.  If a
mechanism existed to svn update a ports tree to the revision level of
the package build I would probably try to use packages for most
and limit building to those ports for which non-default OPTIONS were
employed.  For me, this is the feature that has always been missing.

I recently switched to pkgng and while there is a learning curve I
think it is more versatile and efficient than its predecessor.
Thanks to all who are working to make things better.

Randy



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140206111330.8df9c79e0ec1b9d2ffc9d0a1>