public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: tomjbe@gentoo.org
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula
Date: Tue, 15 Aug 2017 19:49:33 +0200	[thread overview]
Message-ID: <150281937316.24489.8886457675831488368@ham.local.de> (raw)
In-Reply-To: <CAGfcS_mU0uuW2jrpDM-CkYGPi=8TbQN2DtHPQO1BTQvJbAOwvQ@mail.gmail.com>

Quoting Rich Freeman (2017-08-15 14:16:14)
> On Tue, Aug 15, 2017 at 5:19 AM,  <tomjbe@gentoo.org> wrote:
> > Quoting Michał Górny (2017-08-15 08:43:07)
> >> On wto, 2017-08-15 at 06:55 +0200, tomjbe@gentoo.org wrote:
> >> > Quoting Rich Freeman (2017-08-15 00:29:19)
> >> > >
> >> > > I guess to make it a bit more explicit, would it make sense to have 3 flags:
> >> > >
> >> > > client - install the client   (or consider calling it file-daemon instead)
> >> > > director - install the director
> >> > > storage-daemon - install the storage daemon
> >> > >
> >> >
> >> > That would be best, but it is not supported by their (autoconf based) build
> >> > system (and would require a complete rewrite of it). The actual USE flags
> >> > mostly mirrors the switches from the configure script. You can not set them as
> >> > you like, they are not orthogonal E.g. the file deamon (client) will be
> >> > installed unconditionally.
> >> >
> >> > The configure script itself is very brittle atm and needs an urgent overhaul.
> >> > Discussion with upstream goes a long way, but they do not want to change it
> >> > because of the need to retest it on very different systems. No good situation.
> >> >
> >> > A possible idea may be to drop the 'no/client' flag completely. If neither
> >> > 'director' nor 'storage-daemon' is active all that is left would be the
> >> > file daemon.
> >> > What do you think?
> >>
> >> WFM. If the flag doesn't do anything except for disabling the two other
> >> flags, then there's no place for such a flag.
> >>
> > And here comes the problem. USE="bacula-nodir bacula-nosd" does not produce
> > the same set of files as USE="bacula-clientonly". But I will recheck if the
> > difference is of relevance for normal gentoo user.
> 
> It is probably worth understanding the difference.  However, if the
> user sets both -director and -storage-daemon you could also enable
> bacula-clientonly, unless there is some reason somebody might want two
> of those and not the third.
> 
I just tested the different use flags settings as well as directly the
different configure switches. Here is what happens for configure:

* Deactivation of storage-daemon drops the related files.
* Deactivation of director ist ignored by the build system, the director is
  build anyway (One more bug in their build system).
* Activation of clientonly drops both the related files for director and for
  storage daemon.

The ebuild does fix some of the differences:

* +bacula-nodir and +bacula+nosd drops most of the files for these
  functionality, but keeps some more (mostly irrelevant) files over
  +bacula-clientonly.

So from gentoos point of view having nodir and nosd is nearly the same as
having clientonly. That would allow to drop the clientonly flag and keep only
the controling flags for director and storage-daemon.
> >
> >> >
> >> > The downside of that idea is that we diverge from baculas documentation which
> >> > explicitly state that there is a 'clientonly' install.
> >> >
> >>
> >> Upstream install documentation is not relevant to Gentoo. The flag
> >> descriptions in metadata.xml are.
> >>
> > Right. But if we drop a "clientonly" than there is no hint in metadata.xml how
> > to get only the file daemon alone. Some einfo output or similar come to mind.
> >
> 
> You could use einfo.  However, if the docs say what the other two
> flags do then it seems pretty obvious that if you turn them both off
> you end up with only the file daemon.
> 
I think we can find a proper formulation for the use flag description in
metadata.xml, e.g.:

director - Installs the backup director additional to the default file daemon.
storage-daemon - Installs the storage daemon additional to the default file
daemon.

Thomas



  reply	other threads:[~2017-08-15 17:49 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-14 19:58 [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula Thomas Beierlein
2017-08-14 21:55 ` Michał Górny
2017-08-14 22:29   ` Rich Freeman
2017-08-15  4:55     ` tomjbe
2017-08-15  6:43       ` Michał Górny
2017-08-15  9:19         ` tomjbe
2017-08-15 12:16           ` Rich Freeman
2017-08-15 17:49             ` tomjbe [this message]
2017-08-16  1:32               ` M. J. Everitt
2017-08-16  1:45               ` [gentoo-dev] " Duncan
2017-08-16  6:04                 ` tomjbe
2017-08-15  8:37     ` [gentoo-dev] " Kristian Fiskerstrand
2017-08-15  9:33       ` tomjbe
2017-08-15  9:45         ` Kristian Fiskerstrand
2017-08-15 12:21           ` Rich Freeman
2017-08-15 13:25             ` Kristian Fiskerstrand
2017-08-15 14:02               ` Rich Freeman
2017-08-16 12:36 ` tomjbe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=150281937316.24489.8886457675831488368@ham.local.de \
    --to=tomjbe@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox