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 ------------------------------------------------------------------------- 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 BackupPC-users@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
