[TriLUG] local package builds (was: lvm2 cache-pool backported to Ubuntu 14.04?)

Jack Hill via TriLUG trilug at trilug.org
Fri May 1 11:23:06 EDT 2015


On Fri, 1 May 2015, Cristóbal Palmer via TriLUG wrote:

> What some quick investigation makes clear is that my lvm2 is too old:
>
>  $ dpkg -l lvm2 | grep ^ii
>  ii  lvm2     2.02.98-6ubuntu2      amd64    Linux Logical Volume Manager
>
> More searching shows some people willing to install lvm2 from source. We're
> not an org where that's going to fly, and I'd rather not be in the business of
> maintaining an lvm2 backport. Does anybody have experience getting this sort of
> thing to work on Ubuntu 14.04? Did you for example use a backported package
> from Vivid Vervet[1][2]? If so, what were your steps? How do you do maintenance
> updates?
>
> We have workstations running Debian 8.0, CentOS 7, Ubuntu 14.04 and CentOS 6.6,
> so solutions that abandon Ubuntu are something I'm happy to see people write to
> the list about, but remember that my priorities are such that using packages
> that are easily pulled from a reputable upstream without needing to do a local
> build are strongly preferred. I could hopefully have this working today if I
> were willing to abandon that and just build lvm2 from source, but that possibly
> sacrifices repeatability and maintainability for our office.

After some discussion of this issue on IRC, I was surprised by the 
negative reactions to backporting packages or otherwise performing local 
package builds. I am curious why this in. In particular it seems less 
risky than upgrading all the packages to a new (perhaps unreleased) 
release. There is a small setup cost to be able to repeatably and in a 
maintainable way build packages, but having that knowledge and 
infrastructure is just as importing in supporting more than one or two 
machines as a configuration management system.

Is there something I'm missing? Are there bugs in the tools? Do people 
have bad experiences?

I would be happy to expand on some success stories I've had with locally 
building packages such as for software that is not present in the distro 
(fsr), site configuration, getting newer version of software that support 
new features or work around bugs (mailman and dependencies), and 
rebuilding software to better conform with site policies (nss-extrausers).

Best,
Jack


More information about the TriLUG mailing list