-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, March 12, 2008 10:47 AM
To: [email protected]
Subject: BackupPC-users Digest, Vol 23, Issue 25
Send BackupPC-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/backuppc-users
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of BackupPC-users digest..."
Today's Topics:
1. Re: compiling from source vs. installing from a package
(Carl Wilhelm Soderstrom)
2. Re: compiling from source vs. installing from a package
(Carl Wilhelm Soderstrom)
3. Re: compiling from source vs. installing from a package
(Les Mikesell)
4. Re: compiling from source vs. installing from a package
(Carl Wilhelm Soderstrom)
5. Re: compiling from source vs. installing from a package
(Carl Wilhelm Soderstrom)
6. Re: compiling from source vs. installing from a package
(Carl Wilhelm Soderstrom)
7. Re: compiling from source vs. installing from apackage (Jack)
----------------------------------------------------------------------
Message: 1
Date: Wed, 12 Mar 2008 09:33:59 -0500
From: Carl Wilhelm Soderstrom <[EMAIL PROTECTED]>
Subject: Re: [BackupPC-users] compiling from source vs. installing
from a package
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
On 03/12 08:17 , Les Mikesell wrote:
> Carl Wilhelm Soderstrom wrote:
>
> > Some questions have been raised about installing from source vs.
installing
> > from a package and why I don't believe it's good to install directly
from
> > source. I will post my reasons here.
>
> I agree in general, but I look at it as more of a question of whether I
> expect the packaged version to be managed better than I would do it
myself.
In 99% of the cases I've seen with Debian, the distro's package is done
better than I could do it myself. With RPM the figure is slightly worse; but
we're getting pretty far OT here.
> > - It allows you to easily know when a security patch is available, by
using
> > one of the managers like apt, up2date, yum, etc.
>
> That doesn't apply to ones you build yourself.
Only to ones for which there is no distribution package. This happens. Even
so, it's still worth building a package for all the other reasons here.
> > - It allows you to install the exact same software binary to all your
> > machines. (If you were to compile from source there's a good chance
for
> > human error to creep in and compile things differently on different
> > machines, leading to subtle errors which are _really_ hard to track
down).
>
> But, sometimes the differences that happen when you build locally are
> planned by the software author any you lose features in a
> one-size-fits-all build.
Fair enough. I've usually found that Debian has a package that's already
built with those options tho; or is close enough that it's not worth the
extra trouble of maintaining software outside the package system. YMMV.
> > - It allows you to roll back to a previous version easily, if the new
one
> > breaks things.
>
> I haven't found that to be the case with RPM's with dependencies.
I've done it; and while it's painful at times, at least it's *possible*.
Packages allow you to track down all the files associated with a given piece
of software; so you aren't leaving things all over your filesystem which may
come back to bite you at some point in the future.
> Yes, you really don't want to manage very many non-packaged programs,
> but a few aren't a big problem
I try not to get on slippery slopes. :)
> and building locally allows you to stay
> versions ahead or behind the distro-packaged one according to your needs
This is true, and there are times you need to do this. For those instances,
build your own package. Your fellow administrators, and your successors,
will thank you. :) (As a consultant I've had to clean up entirely too many
machines which had lots of software installed from source; and quite often
the policy is to re-install the whole OS because that was the best way to
put the machine back to a known state).
--
Carl Soderstrom
Systems Administrator
Real-Time Enterprises
www.real-time.com
------------------------------
Message: 2
Date: Wed, 12 Mar 2008 09:39:06 -0500
From: Carl Wilhelm Soderstrom <[EMAIL PROTECTED]>
Subject: Re: [BackupPC-users] compiling from source vs. installing
from a package
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
On 03/12 10:14 , Stephen Joyce wrote:
> Personally, after years of installing everything from source, I now use
> packages for most software.
I went through the same process myself, after spending a lot of time doing
things the hard way, then learning from people who are more experienced than
myself.
> Debs, RPMs, or some other package format, and the
> associated tools, are almost mandatory if you manage more than 5 or so
> machines. And when you get to 100 or more, even some of the vendors' tools
> must be, ahem, coerced, to make them work well without babysitting them.
Or else you spend a lot of time babysitting the differences between all the
machines (which is what I do); even with packages to help you along the way.
> The only things I install from source and don't create a .deb for are
> mission-critical server software. This includes things like imapd,
> my webmail server, and yes.. backuppc and backuppc4afs
> (http://backuppc4afs.sourceforge.net) </plug :-)> Those I just document to
> hell and back.
Lack of documentation may be the biggest problem with software compiled from
tarballs. I'd prefer that documentation be done automatically tho; because
metal and plastic machines are less prone to errors than meat machines
(humans) are.
I'm sure your fellow administrators and successors will thank you for your
documentation. :)
--
Carl Soderstrom
Systems Administrator
Real-Time Enterprises
www.real-time.com
------------------------------
Message: 3
Date: Wed, 12 Mar 2008 10:03:41 -0500
From: Les Mikesell <[EMAIL PROTECTED]>
Subject: Re: [BackupPC-users] compiling from source vs. installing
from a package
To: Carl Wilhelm Soderstrom <[EMAIL PROTECTED]>
Cc: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Carl Wilhelm Soderstrom wrote:
>
>> and building locally allows you to stay
>> versions ahead or behind the distro-packaged one according to your needs
>
> This is true, and there are times you need to do this. For those
instances,
> build your own package. Your fellow administrators, and your successors,
> will thank you. :) (As a consultant I've had to clean up entirely too many
> machines which had lots of software installed from source; and quite often
> the policy is to re-install the whole OS because that was the best way to
> put the machine back to a known state).
But, the extra steps in building your own package are just more places
where things can go wrong - and places that you will second-guess the
author's choices about install locations, etc. You are right that if
they are done correctly it is a good thing and some/most of the work may
apply to the next release, but there is not much reason to think that if
don't get a source install right without packaging that you would build
a usable package.
--
Les Mikesell
[EMAIL PROTECTED]
------------------------------
Message: 4
Date: Wed, 12 Mar 2008 10:09:57 -0500
From: Carl Wilhelm Soderstrom <[EMAIL PROTECTED]>
Subject: Re: [BackupPC-users] compiling from source vs. installing
from a package
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
On 03/12 09:42 , Ambrose Li wrote:
> On 12/03/2008, Carl Wilhelm Soderstrom <[EMAIL PROTECTED]> wrote:
> > - It allows you to easily know when a security patch is available, by
using
> > one of the managers like apt, up2date, yum, etc.
>
> Unless the package has been abandoned by the packager, and you found
> out that there should have been a security package a year ago. You try to
> upgrade your package and found that even old versions of your package
> have completely disappeared. The only way to apply the patch is to
> compile it yourself, but you have no idea how the package was compiled.
This does indeed happen; and it's a valid point. It does not invalidate my
contention that the proper solution in that case is to build your own
package. It's rare that you can't find a source package for some version of
the binary package; and modify it for your own purposes.
> > - It allows you to install the exact same software binary to all your
> > machines. (If you were to compile from source there's a good chance
for
> > human error to creep in and compile things differently on different
> > machines, leading to subtle errors which are _really_ hard to track
down).
>
> This is very valid, but when you compile your own software you save
> your commands in a file, don't you? =)
That's what your RPM .spec file is for, or the dpkg equivalent. :)
That said, you have a point; but I will also point out that
autoconfig/automake may find that due to slight differences between software
installations on machines (bound to happen; it's almost impossible to keep
two machines that are not upgraded in absolute lockstep, completely
identical); you may get differences in behavior. (You can get differences in
behavior when installing from packages, but they're more likely to be due to
config file differences, which are much easier to track down).
> > - It allows you to roll back to a previous version easily, if the new
one
> > breaks things.
>
> Provided that you have saved the previous package yourself. If you
> did not do it and the package has been pulled, you are on your own.
This is true. That said, I've rarely had to do it anymore (Debian has gotten
a lot better over the years, and when using distro-compiled packages I've
had less need to do it than when using custom-compiled packages). Old
packages are indeed possible to find sometimes tho, if you look around
enough.
> > - It gives you more assurance that the software will be compatible with
your
> > already-existing software (Debian's quality control is much better
than
> > mine would be).
>
> Unless they get the dependencies wrong. Which is not impossible.
> I have seen it both ways (dependency too specific, e.g., specifying
> apache instead of a web server; and missing dependencies
> altogether). Then you get a false sense of compatibility until you
> file a bug, and get told that you have not upgraded the whole
> package. This is not even rare.
I've seen this happen too. I've found Debian to be better than Red Hat that
way; but I've been bitten by Debian package upgrades, even in the stable
distro. Still, it happens less than it would if/when I was building the
packages myself.
> The reverse is also true, i.e., it contains extra features that deviate
> from the unpatched version that the original devs refuse to support
> you.
I've seen this as well, and it's a valid point. I've found that more often
than not I like the patches they add in tho. :)
> And when you file bugs, do you file a bug to the original dev
> (which might ignore you unless you can prove that it's not a bug
> in your package), or do you file a bug to your packager? Do you
> need to check what kind of patches they have applied every time
> you file a bug? Can you understand all the patches? My
> experience with filing bugs with Debian is that it is a generally
> useless exercise.
I've had pretty good luck filing bugs with Debian packagers. YMMV.
> I don't find this true. Often, when I am asked the questions, unless I
> have already used the software before, I have no idea what they
> are talking about. I end up having to skip all the questions and later
> read the config file myself to figure out what has been asked.
This is true. It gets easier after the second or third time tho; and I like
being exposed to the provided explanations and warnings.
> But, that said, I know I am not a good administrator, but not for the
> cited reason, and I don't believe the cited reason is valid for labelling
> someone a bad admin.
I made an overly broad statement, and I apologize for that.
--
Carl Soderstrom
Systems Administrator
Real-Time Enterprises
www.real-time.com
------------------------------
Message: 5
Date: Wed, 12 Mar 2008 10:18:14 -0500
From: Carl Wilhelm Soderstrom <[EMAIL PROTECTED]>
Subject: Re: [BackupPC-users] compiling from source vs. installing
from a package
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
On 03/12 10:03 , Les Mikesell wrote:
> But, the extra steps in building your own package are just more places
> where things can go wrong
I find it much easier to fix a broken package than a broken tarball
installation; because when you remove the broken package you're more likely
to get all the files. (Not necessarily true with RPM). This means that you
don't have cruft building up on your system.
Installing from a self-compiled package also means you can test it on one
machine and then put the identical code on a production machine. (We all
know that it's best to have test and production environments, even if things
don't always work out that way).
> - and places that you will second-guess the
> author's choices about install locations, etc.
There are a few things that are inane about the Filesystem Heirarchy
Standard (which Debian is pretty good about following); but by and large it
makes sense, and if you have multiple administrators it's best to all follow
the same standard, even if you don't like it personally.
> You are right that if
> they are done correctly it is a good thing and some/most of the work may
> apply to the next release, but there is not much reason to think that if
> don't get a source install right without packaging that you would build
> a usable package.
Agreed.
My point is not that you can't do things well and effectively by installing
from source; people have done it for years. My point is that humans make
mistakes, and packages make it easier to recover from mistakes.
--
Carl Soderstrom
Systems Administrator
Real-Time Enterprises
www.real-time.com
------------------------------
Message: 6
Date: Wed, 12 Mar 2008 10:29:52 -0500
From: Carl Wilhelm Soderstrom <[EMAIL PROTECTED]>
Subject: Re: [BackupPC-users] compiling from source vs. installing
from a package
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
I put forth my listed points (and a few more) at this page:
http://backuppc.wiki.sourceforge.net/install_from_package
I put it under the off-topic section since it really is off-topic for the
list. I invite others to contribute their views to it; perhaps in a section
underneath which offers counterpoints and the advantages of compiling
directly from source tarballs.
I *do* myself compile directly from source tarballs on occasion; but only on
test machines (like a vmware session), and for purposes of trying out the
software, and only when there isn't a similar package available.
--
Carl Soderstrom
Systems Administrator
Real-Time Enterprises
www.real-time.com
------------------------------
Message: 7
Date: Wed, 12 Mar 2008 10:47:17 -0500
From: "Jack" <[EMAIL PROTECTED]>
Subject: Re: [BackupPC-users] compiling from source vs. installing
from apackage
To: "'Carl Wilhelm Soderstrom'" <[EMAIL PROTECTED]>,
<[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
The great thing about compiling it on your machine is you KNOW that it is
compiled using YOUR libraries, and does not make assumptions about other
'supported' libraries being installed. If you 'tweak' the config, you can
even get it optimized for your CPU and leave out some 'features' you don't
need. (I haven't run on a i386 without a built in floating point unit for a
long time, so FPU emulation software is probably not needed!)
But since most of my machines are 'fast enough' for me, I do load binary
packages when possible. But I have also installed BackupPC from tarballs
because the Ubuntu support folks (volunteers, so I can't rag on the to much)
don't seem to keep up very closely.
Just a thought.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Carl
Wilhelm Soderstrom
Sent: Wednesday, March 12, 2008 10:30 AM
To: [email protected]
Subject: Re: [BackupPC-users] compiling from source vs. installing from
apackage
I put forth my listed points (and a few more) at this page:
http://backuppc.wiki.sourceforge.net/install_from_package
I put it under the off-topic section since it really is off-topic for the
list. I invite others to contribute their views to it; perhaps in a section
underneath which offers counterpoints and the advantages of compiling
directly from source tarballs.
I *do* myself compile directly from source tarballs on occasion; but only on
test machines (like a vmware session), and for purposes of trying out the
software, and only when there isn't a similar package available.
--
Carl Soderstrom
Systems Administrator
Real-Time Enterprises
www.real-time.com
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges.
Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
BackupPC-users mailing list
[email protected]
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
------------------------------
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
------------------------------
_______________________________________________
BackupPC-users mailing list
[email protected]
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
End of BackupPC-users Digest, Vol 23, Issue 25
**********************************************
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
BackupPC-users mailing list
[email protected]
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
