[TriLUG] Vagrant image mentioned in Ansible presentation last night

[Joseph S. Tate via TriLUG]

On Fri, May 13, 2016 at 1:43 PM Phil Smith via TriLUG <trilug at trilug.org>
wrote:

> As this wasn't related directly to Ansible, I didn't want to sidetrack the
> presentation with the oversized Vagrant image Joseph mentioned.
>
> 1) The probable cause of the image increasing from 0.3G to 1.3G was the
> '*.deb' package files downloaded during the upgrade.  Use 'apt-get clean'.
> On Gentoo I manually delete old /usr/portage/distfiles/*.tgz since they
> will be downloaded again if needed, and in about a year of updates this
> directory will dwarf the OS.  Since Gentoo often points directly upstream,
> there is a danger that a package may be abandoned either by the maintainer
> or Gentoo, so in that case one would want to save an obscure package before
> it vanishes forever.
>
> That's a good first start, but you also have to zero out the drive. Any
written clusters are still allocated blocks typically. It's an art form to
get a small base image in my experience.


> 2) Upgrading a 6 year old image to current does not necessarily produce
> the same system continuous updates over the 6 years would as sometimes
> temporary build bridge code across major updates appears.  In many cases it
> may even fail in non-LTS systems as it is assumed one will not start that
> far back.  The old "system test" concept is also violated because test
> groups do not test this path.  The real breakage points are crossed with
> upgrades to gcc and glibc.  In the case of rolling-release distros one
> downloads the most recent build (usually less than 1 week old) and then
> does a small update.  It is easier to see how starting from an older image
> can produce a different end result in a source-based system where one
> actually recompiles a new gcc (since the first try was built with the
> previous gcc), then recompiles the system, especially the libraries gcc
> uses, then repeat since you finally have gcc+new_system_libs all current
> which is the definition of truly having a "real" gcc-4.9.3 (this takes
> perhaps days and is done only by someone who wants to be really sure
> everything is current.  Although gcc/g++ is getting better, sometimes one
> has to search for a newer/older version to successfully build a package
> like libreoffice with 'Segmentation Fault' on fancy C++ code.
>

Not as much of a worry for distros with file manifest packaging systems and
don't build locally. Uninstalling a package removes all the files in the
manifest. The differences over time would be in artifacts (database journal
files, data formats, etc.)

I should like to note that I typically use "$LATEST_UBUNTU_IMAGE in AWS
when creating new instances. It's just that the precise virtualbox .box
file doesn't get rev'd ever, so it's ancient.