On Wed, 07 Mar 2012 08:46:23 +0100, Sylvain wrote: > 2012/3/6 Camaleón <noela...@gmail.com>:
>> Well, there are some packages that in addition to be installed have to >> be configured to be run on booting. I mean, the fact a service is not >> started by default cannot be considered a bug or error "per se". > > Sure, but you usually have either configuration files to edit, or a note > in the readme file stating that you'll need some additional steps to > make the package work if you're using some special configuration. Yes, but this does not seem to be the case. What I wanted to note is that an installed package does not have to be enabled by default, it can need manual intervention. > Also the resolution of the problem was not straightforward; in fact I > was writing to the list to get a solution to my problem when the > solution came to my mind. "Problems" and "straightforward" do not usually go in the same phrase, by their own nature :-) >> So backuppc daemon is starting but fails because it cannot access to >> the configured external USB hard disk? You can check the service status >> with "service backuppc status". > > Yes, the /removable/sbackup/backuppc directory is empty since autofs has > not started yet and thus has not created the directory yet. Okay, then the service is started but fails. >> Mmm, I would open a bug against the package it self (that is, backuppc) >> to get some feedback from the package maintainers about this situation. >> >> In principle (though I don't know BackupPC requirements in deep), it >> should not require "autofs" by default (nor smb, nfs...) because there >> can be people/installations not having that service even installed. > > Sure. Maybe the best solution is a note in the readme file for autofs > users. I'll file a bugreport against backuppc. Sure, documenting that kind of things never hurts. Anyway, I would have expected some kind of warning at the logs coming from backuppc indicating a problem for accessing to the configured mount point which was not available at that time and thus failing. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jj7jul$ujn$5...@dough.gmane.org