Reducing the size of the ports tree (brainstorm v2)

Thu Nov 6 00:00:46 UTC 2014

On 11/05/14 13:30, Mark Felder wrote:
>
> On Wed, Nov 5, 2014, at 10:16, Roger Marquis wrote:
>> Was a time when FreeBSD was believed to be a more stable and compatible
>> platform than Linux.  Of course all that backwards compatibility was
>> thrown out the window with this year's make and pkg updates, which made
>> management at my business much more receptive to the linux admin's calls
>> for linux-everywhere, but this is a matter for the community to decide.
>>
> FreeBSD spent 20 years not changing and you know what we got for it? An
> ugly mess. Please keep in mind that nobody is changing the core OS.
> They're simply bringing our package mangement from the 1990s to the
> 2000s, and hopefully after that dust settles we can move to the 2010s.
> Yes, through this transition it's painful if you are used to never
> having to touch your custom ports. The change important and the benefits
> are far-reaching.

You are grouping two distinct changes together, and disparaging,
non-specifically, the
old ports (package)  system which served here, well, 2004 January to the
present day.
I sent another email, detailing in which, many > one files in the ports
tree may be a bad idea.

Having transitioned to pkg successfully on one machine,  that I can
still not upgrade
pkg > pkg without hacks, and halfway on another, on which pkg2ng did not
work, and
is sort of in limbo ( an inaccurate pkg database, and buggy operation of
a few pkg
commands, and out of the blue segmentation faults ) I see pkg as more
convenient BUT
less reliable.  

Specifically here,
An ugly mess.... not
1990s 2000s    .... not reliable enough yet
benefits far-reaching .... maybe in the future.  Saving time here but
with uncertainty.

>
> I don't care how good of a FreeBSD admin anyone is. You can't tell me
> you won't find any of the following instances on your servers before
> pkgng:
>
> - duplicate packages registered in pkg_info
I could simply /bin/rm -rf  the duplicate subdirectory.

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

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

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

>
> 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. Less
preplanning or experience, and your scenario may be right, but numerous
blogs of
administering servers I've read over the years, and in FreeBSD books,
paint an easier and
more seamless sequence of events with each upgrade, most of each not
being abstracted
away from the command line, but line-by-line expertly managed.

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

> In fact, that was often the
> solution where I used to work -- wait until a serious enough
> vulnerability is affecting the server and then reinstall from scratch
> with the latest RELEASE.

>
>> For most of us end-users it doesn't matter as we use portsnap
>> (and update speed really isn't an issue).
>>
> 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.

>  This
> will increase consistency, lower false bug reports, and greatly
> ease/increase adoption by lowering the barriers

But "this" here you have included both pkg (not yet seamless or as

reliable in my opinion) and the new scheme of abstracting away the
information in
the smaller files.  I see more bug reports from pkg (from here for
instance)...   It seems
to early to call the above as a certainty. 

Apologies if I am sounding way critical upon wishing to simply advocate
caution on any
divergence from the reliability the ports tree and legacy package served
for years upon
years.  While pkg is saving time here,  it has raised new fears about
the validity of my
recommendations of using pkg/ports to others... not having any poudriere
experience, not
knowing how many low-powered routers pkg may not work on, having disks
that may
not upgrade well with pkg2ng if ever...   other unanswered questions.
>  and raising the sanity
> of a FreeBSD server over its lifecycle.
>
> -2c
> _______________________________________________
> freebsd-ports at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"