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

[Freddie Cash]

On Thu, Feb 6, 2014 at 8:13 AM, Randy Pratt <bsd-unix at embarqmail.com> wrote:

> On Wed, 5 Feb 2014 23:26:18 -0800
> Kevin Oberman <rkoberman at gmail.com> wrote:
>
> > On Wed, Feb 5, 2014 at 10:45 PM, Matthew Seaman <
> > m.seaman at infracaninophile.co.uk> wrote:
> >
> > > On 05/02/2014 23:57, Kevin Oberman wrote:
>


> > 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 at 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.
>
> That would be a *very* useful feature.  To be able to query the remote pkg
repo to get the svn revision number of the ports tree that was used to
build the repo.  Then you could pass that to svnup/svn to sync your local
ports tree to the same revision.  Then you could very easily mix/match
local ports installs with remote pkg installs, as the versions for
everything would match.

Once the multi-repo features of pkg are up to snuff, perhaps adding a
"local" repo would also help.  Any software installed via the ports tree
infrastructure would get tagged as part of the "local" repo.  Then one
could query the pkg database to get a list of software that came from the
"local" repo, so we know which bits needs to be reinstalled/upgraded from
the ports tree.

Which, could easily tie into poudriere (or portmaster) for building the
local ports en-masse.​​


-- 
Freddie Cash
fjwcash at gmail.com