Hi,
Jon Craig wrote on 2008-07-24 11:31:58 -0400 [Re: [BackupPC-users]
[BackupPC-devel] Ubuntu Upgrade from 3.0.0 to 3.1.0 problem]:
> On 7/22/08, Holger Parplies <wbppc AT parplies DOT de> wrote:
> > [referring to mixing package and tarball] There is
> > no simple way to recover from this.
>
> Here's what I was gonna do:
> Shutdown BackupPC
> Save the /etc/backuppc directory and move the /var/lib/backuppc
> directory to a safe place.
> Force remove the Ubunto package
> run the install for the tarball to get a plain jane version
depending on what files might be left over from the tarball update, this might
not work, but I guess you'll see if it doesn't.
> Put /etc/backuppc to /etc/BackupPC and /var/lib/backuppc back to its place
> Fixup any path issues with file location in config.pl
> Start BackupPC
Of course it's your choice whether you prefer the tarball or a package. I'd
prefer the package. Have you got a specific reason for updating to 3.1.0?
> > It still is /etc/BackupPC for the tarball version. The Debian and
> > Ubuntu packages use /etc/backuppc. I think this is a good idea, because it
> > discourages mixing up package and tarball :-).
>
> Not sure I agree with this or at least with the manner of implementation.
>
> 1st, Ubuntu maintainers must have hand modified the code to get it to
> recognize /etc/backuppc as a place to check for configs. This is a
> very bad thing to have happening as you have unversioned code variants
> in the wild and users who don't even know it.
This is the case for every package which doesn't adhere to every aspect of
distribution policy. You have path modifications, modified defaults,
integration into debconf, modifications to make dependencies work, maybe even
security fixes [most of that does not apply to BackupPC], just to name the
first things that spring to mind. From Ubuntu's point of view, there is one
Ubuntu package [per release] that people should be using. There should not
usually be unpackaged software installed, at least not if it is also available
as a package. The packages are supported, unpackaged software isn't. I don't
see your issue with "unversioned code variants in the wild".
Additionally, you should be able to see exactly what changes to the upstream
package were made - that is what the .diff.gz files in the archives are for
(and, to some extent, the changelogs).
It is the distribution's responsibility to make sure the system "feels"
consistent, even if multiple upstream authors have different tastes.
/etc/BackupPC may be a great idea from Craig's point of view, but in Debian
(and presumably Ubuntu), it does not seem to fit in well. It would be
confusing to users that just use the package and don't follow the upstream
mailing lists. Debian (and presumably Ubuntu) have rather strict policies,
so it might even be a question of either making a harmless change or not
getting the package into the distribution at all.
> 2nd, configure.pl didn't detect the fact that backuppc wasn't BackupPC
> and installed. It also didn't create a BackupPC directory. If your
> gonna rely on an alternate name to indicate a package install then
> configure.pl should have recognized this and bombed out with an
> appropriate message: "tsk, tsk, tsk, don't mix packages with
> tarballs".
The name is not meant to indicate a package install and cannot be guaranteed
to do so either. I believe the tarball lets you choose your own value for
ConfDir, so you might have tarball installations using /etc/backuppc too. And
you might have packages that use /etc/BackupPC, where it would be just as
inadvisable to upgrade with a tarball.
The upstream author cannot anticipate what modifications people packaging his
software are going to make, so he (or rather his install script) can't
recognize packages.
Moreover, the state of your packaging system is your concern as administrator,
not BackupPC's. If you use a packaging system, you should be aware of the
consequences of unpackaged installations. If your uid is 0, you alone are
responsible for knowing the consequences of your actions. You might have valid
reasons for upgrading a package with a tarball. You might not care about the
state of your packaging system. Fine. Your choice. The job of the installer is
to perform an installation or upgrade, not to reason with you whether it's a
good idea or not.
> 3rd, the way in which BackupPC is trying to determine its ConfDir
> needs to be addressed. The magic $useFHS variable (coupled with
> packagers editing the code to make the match work) is bound to cause
> problems.
Only if used incorrectly. Just about anything is bound to cause problems if
used incorrectly.
> BackupPC should set a location for a config file that
> points to the configuration directory /etc/BackupPC.conf or
> /etc/default/BackupPC.conf that holds possibly one thing ConfDir =
> /etc/BackupPC or whatever.
You would have the same problem again. The packages would move this file to
/etc/default/backuppc to adhere to distribution policy.
> You should also be able to specify the
> configuration directory on the command line BackupPC --confdir=XXX for
> those poor souls who feel strongly that the location you chose for the
> immovable conf file was inappropriate.
That might be a good idea. It really wouldn't solve anything, though.
Packagers would probably modify the code anyway. For the daemon, you could add
'--confdir=XXX' in the rc script, and it might be able to propagate it to the
programs it calls, but for everything you call on the command line, you would
need to add the option every time. How unconvenient and error-prone would that
be?
Jon Craig wrote on 2008-07-24 17:58:38 -0400 [Re: [BackupPC-users]
[BackupPC-devel] Ubuntu Upgrade from 3.0.0 to 3.1.0 problem]:
> Now I remember why I mixed the tarball with the ubuntu package, it was
> because it was suggested on the wiki (
> http://backuppc.wiki.sourceforge.net/supporting+distros ):
I'll change that as soon as I feel inclined to create a wiki login, which I
don't anticipate being anytime soon [an account for *browsing* a wiki? Whose
idea was that?].
My guess is, a warning as to messing up the state of your packaging system
database (dpkg) and the correct conf-dir parameter should be added.
> Ubuntu 7.04 (aka feisty fawn)
> backuppc v2 and v3.0 via apt (v3.0 is in backports)
-> to install v3.1, first install v3.0 by "apt-get install backuppc"
-> (from backports), then download the regular install script from
-> http://backuppc.sourceforge.net/ and run it, it will update you to
-> v3.1 quite nicely
+> If you *need* to install an unpackaged version, you have several options.
+> First, build a package yourself and install that. This is rather
+> complicated if you are not familiar with the process of building a .deb
+> package, but it is the only way that will not interfere with dpkg's state.
+> If you cannot do that, you might as well install the tarball from
+> http://backuppc.sourceforge.net/ [hopefully described elsewhere].
+> Alternatively, install the latest packaged version with "apt-get install
+> backuppc" (presumably from backports), then download the regular install
+> script from http://backuppc.sourceforge.net/ and run it *with the parameter
+> "--config-path=/etc/backuppc/config.pl"*. This may update you to the newest
+> version, but you risk confusing your packaging software. The benefit over
+> installing the tarball is doubtful.
Martin Leben wrote on 2008-07-25 11:54:22 +0200 [[BackupPC-users]
"BackupPC_compressPool -t" says "Finished with 1423 errors!!!!"]:
> [...]
> I use version 3.1.0-2~bpo40+1 on Debian Lenny.
I suppose this means 3.1.0 is also in backports. The last time I checked,
there were no scary dependencies that should prevent installing any BackupPC
.deb in just about any Debian/Ubuntu system *except this one*:
libfile-rsyncp-perl depends on the version of libc6 it is built for, so if you
need a newer libfile-rsyncp-perl than your distribution release contains,
you'll pull in unwanted dependencies.
You might want to try this on an Ubuntu box where BackupPC is currently not
installed. Removing a [partly] installed package should be simple, even if
something does go wrong.
Kurt Tunkko wrote on 2008-07-25 09:12:10 +0200 [Re: [BackupPC-users]
[BackupPC-devel] Ubuntu Upgrade from 3.0.0 to 3.1.0 problem]:
> [...]
> from my research some time ago, I didn't find any information that
> somebody has successfully installed BackupPC v.3.1 on Ubuntu.
> [...]
> If you've successfully updated BackupPC to 3.1 on ubuntu I would really
> appriciate if you write a short howto.
Be the first and do it ;-).
Les Mikesell wrote on 2008-07-24 11:13:28 -0500 [Re: [BackupPC-users]
[BackupPC-devel] Ubuntu Upgrade from 3.0.0 to 3.1.0 problem]:
>
> My 2cents worth: I think all of the packaging attempts err in putting
> any of it in the 'standard' places. In my opinion, backuppc should be
> self-contained in its own filesystem to whatever extent possible -
I agree that this would be optimal.
> something like /opt/backuppc. Even with a tarball install you don't
> quite get this because of the needed non-standard perl modules and the
> setup for the web server.
As for the Perl modules, sharing them with the rest of the system has
advantages like, for instance, security support. Having a working "backup" of
the Perl modules under $TopDir (and put that in the Perl include path behind
the system defaults) would get you what you want. You use the system versions
in the normal case and the backups if there are no system versions available.
Hopefully, there are no subtle differences that will bite you when it hurts
most.
Web server setup is more complicated, because it obviously depends on the
web server :). But you *could* move them around and have a softlink in
/etc/apache2/sites-available/ or whatever. If you can do this by hand, you can
also create a package where it is set up in this way (it will probably depend
on a particular web server though).
> I realize this concept conflicts with normal packaging guidelines to
> install everything in standard places, but the reason you are keeping
> backups is that everything normal may go wrong.
Not necessarily, but often enough.
One reason for packaging guidelines is that an installed system is
supposed to work, regardless of which packages you combine in which way
(dependencies permitting). With BackupPC and all its components on an
individual file system, which might be a remote resource, you'd need to start
the daemon after any service possibly providing that resource. While that is
not a problem, the same now applies to any web server you might be using. Or
you could reload the configuration of [any web server] in the init script of
BackupPC. Hmm. And this is only the obvious dependency. Are there any others?
Is there the possibilty of circular dependencies?
It is without doubt feasible for an individual administrator to set things up
this way in his controlled environment. Furthermore, an individual
administrator might *require* such a setup. Many people doing backups on home
computers don't. And I believe it would be difficult for a distribution to
make it work 'out of the box'. It's just not a one-fits-all type of thing.
Regards,
Holger
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
