Summary: | app-backup/bacula ebuild: bacula-sd only still requires database | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Christian Samsel <csamsel> |
Component: | Current packages | Assignee: | Thomas Beierlein <tomjbe> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | Keywords: | EBUILD |
Priority: | Low | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Christian Samsel
2017-02-20 21:50:46 UTC
(In reply to Christian Samsel from comment #0) > Hi, > I have a machine where i only want to run the bacula storage daemon > (bacula-sd), bacula director is running elsewhere. The storage daemon does > not need a database connection, but the ebuild does not allow to be built > without: > Right. And that is by intention. Please read lines 177ff. in the ebuild and look up the mentioned bug #311099 starting at comment #2. > i can activate sqllite to least not draw mysql or postgres in, but that's > still a bit inconvenient. > That is quite true but not under our control. Sorry. > Also having the useflags bacula-clientonly bacula-nosd bacula-nodir is very > inconsistant. I'd rather see useflags bacula-withfd bacula-withsd > bacula-withdir - bacula-withdir requiring a database. The use flags mirror the configure options from baculas autoconf script. And true the logic is a little bit weird. Changing the USE flags to the suggested above syntax brings two problems: - All user already using bacula for some time have to switch over and - Adding another layer of converting our use flag meaning to the according autoconf options brings additional complexity (and bug sources) to the already complex ebuild logic. P.S. Be patient wrt to further discussion. I am away for a week or so and can only answer afterwards. Thanks for your answer. I had a deeper look at the ebuild and it seems there is not a lot to do then with the upstream restrictions regarding the build process. Personally i'd still like to change the useflags. I'd rather have complexity in the ebuild then on the user side. I agree, it has some negative impact for people who changed them (including me) but as long as the previous default behavior is kept (build everything) it should be resonable. The 2nd best option would probably be to extend the EINFO with information regarding this issue. I would not necessary expect people to go through the ebuild source file after beeing puzzled by this (i didn't do that either) |