Reducing the size of the ports tree (brainstorm v2)

[Mark Felder]

On Wed, Nov 5, 2014, at 18:01, Jeffrey Bouquet wrote:
> 
> On 11/05/14 13:30, Mark Felder wrote:
> >
> > - duplicate packages registered in pkg_info
> I could simply /bin/rm -rf  the duplicate subdirectory.
> 

Your're treating the symptom not the problem. This solves nothing and
leaves potentially vulnerable, untracked libraries and binaries on your
system and you can't be sure which one future port builds are linking
against. 

> > - leftover files *everywhere*. find /usr/local -type f -print0 | xargs
> > -0 -n50 pkg_which | grep "not found"
> A small price to pay for stability.  And what if pkg which (sqlite) is
> more prone to
> breakage, obsolete libraries, wrong compiler >> libmap...  vs pkg_which
> which
> could be resurrected as a backup... I hope continually
>

I don't understand which faults you're trying to point out here.
Breakage and obsolete libraries? pkg-static....
 
> > - broken binaries discovered via pkg_libchk
> One can easily have that now,  pkg upgrading to ruby20 default when
> ruby19 is still
> installed or something...  or my limited experience is not the norm
> 

No you can't. pkgng doesn't install packages without their dependencies.
This would all be fixed by the next package set.

> >
> > This is disgusting. You might as well just be extracting tarballs and
> > not using a package manager because the only benefit you're gaining from
> > the old ports tree is the automation of *building* and *installing*.
> Portmaster handily handled the switches -d -B -P -i -g  (ports unless
> packages upstream)
> Why disparage that?  Pure packages is not for everyone, and that in
> itself AFAIK is a
> feature not a bug of FreeBSD... 
>

Portmaster is not part of FreeBSD, and why are we relying on a third
party tool to fix bad design?
 
> >
> > Here's the lifecycle of a typical pre-pkgng server:
> >
> > 1) Install FreeBSD
> > 2) Install your ports/packages
> > 3) Server is in production
> > 4) Attempt to update ports/packages
> > 5) Disaster is now waiting to happen
> 3a... Production?  update on a second machine, roll out to the main one.
> No disaster.

But how do you get the updated ports/packages onto the production server
without building them? I surely hope you're not building and installing
them on another server and manually copying the files/libraries over. If
you used a package server (tinderbox) that same concept is what we're
recommending.


> > Every time you need to update you might as well rm -rf /usr/local and
> > start over. 
> I upgraded 5 > 5 > 5 > 6 > 7 > 8 > 9  and instances within each one,
> losing mutiple
> hard drives, but files in /usr/local still exist from 2004...

This is terrifying for reasons previously explained.

> > Some ports even barfed all over the base system, so
> > reinstalling wouldn't be a bad idea either. 
> I read reinstalling not a bad idea, but only in the problematic case.
> 

Untracked libraries and executables all over your OS is a problematic
case.

> > The goal is to make pkg the norm and ports the very rare exception.
> Why 'very rare?  '  I always thought that they were to work in tandem. 
> Isn't tweaking of
> ports on one's machine consistent with knowing the ins and outs of all
> the ports as well
> as package workings? Make targets?  etc.
>

Mixing packages and ports is *not* supported and never has been. This is
another cause of unnecessary bug reports.

The only "tweaking" you should be doing is changing port build options,
and they'll be available via (sub)packages according to the current
roadmap. Only in rare circumstances should you need to manually build
ports.

> not having any poudriere
> experience

This is very simple to solve, and I think you'll love it. You get all
the power of ports and confidence in your system.

> , not
> knowing how many low-powered routers pkg may not work on, 

pkgng is faster than pkg_ in many ways. I don't see a concern here.

> having disks
> that may
> not upgrade well with pkg2ng if ever...

You're basically asking pkgng to be able to import data from an
unsanitized, schema-less database with no constraints and have it work
perfectly. Not even divine intervention could make this work reliably.