[gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[Thomas Beierlein]

[-- Attachment #1: Type: text/plain, Size: 371 bytes --]

Bacula ebuilds uses some weird USE flags with mostly negative
logic ('do not build ..') coming from their build system.

With the actual major release (bacula-9.0.3) we should try to switch to
something more sane. I picked up the new flags from app-backup/bareos as
both ebuilds have a common anchestry.

Please comment on the proposed news item. 

Thanks,
	Thomas


-- 

[-- Attachment #2: 2017-08-14-bacula-changed-use-flags.en.txt --]
[-- Type: text/plain, Size: 1031 bytes --]

Title: Changing USE flags for >=app-backup/bacula-9.0.3
Author: Thomas Beierlein <tomjbe@gentoo.org>
Content-Type: text/plain
Posted: 2017-08-14
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: <app-backup/bacula-9.0.3

Until now Bacula ebuilds uses the following set of USE flags:

* 'bacula-nodir' and 'bacula-nosd' are inhibiting installation of the 
  backup director and backup storage daemon respectively, 
* 'bacula-clientonly' drops all components but the file daemon.

Due to the negative logic of that flags the correct meaning is sometimes
difficult to grasp. Starting with version bacula-9.0.3 these USE flags will be
changed as follows:

* 'bacula-clientonly' becomes 'clientonly'
* 'bacula-nodir' will be replaced by 'director' but with inverted logic 
* 'bacula-nosd' will be replaced by 'storage-daemon' (also inverted).

'director' and 'storage-daemon' will be active by default resulting in an
installation with backup director and storage daemon enabled.

Please adapt your USE flag settings accordingly.

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1278 bytes --]

On pon, 2017-08-14 at 21:58 +0200, Thomas Beierlein wrote:
> Title: Changing USE flags for >=app-backup/bacula-9.0.3
> Author: Thomas Beierlein <tomjbe@gentoo.org>
> Content-Type: text/plain
> Posted: 2017-08-14
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: <app-backup/bacula-9.0.3
> 
> Until now Bacula ebuilds uses the following set of USE flags:
> 
> * 'bacula-nodir' and 'bacula-nosd' are inhibiting installation of the 
>   backup director and backup storage daemon respectively, 
> * 'bacula-clientonly' drops all components but the file daemon.
> 
> Due to the negative logic of that flags the correct meaning is sometimes
> difficult to grasp. Starting with version bacula-9.0.3 these USE flags will be
> changed as follows:
> 
> * 'bacula-clientonly' becomes 'clientonly'

This is still negative logic in disguise. clientonly = noserver.

> * 'bacula-nodir' will be replaced by 'director' but with inverted logic 
> * 'bacula-nosd' will be replaced by 'storage-daemon' (also inverted).
> 
> 'director' and 'storage-daemon' will be active by default resulting in an
> installation with backup director and storage daemon enabled.
> 
> Please adapt your USE flag settings accordingly.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 988 bytes --]

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[Rich Freeman]

On Mon, Aug 14, 2017 at 5:55 PM, Michał Górny <mgorny@gentoo.org> wrote:
> On pon, 2017-08-14 at 21:58 +0200, Thomas Beierlein wrote:
>>
>> * 'bacula-clientonly' becomes 'clientonly'
>
> This is still negative logic in disguise. clientonly = noserver.
>
>> * 'bacula-nodir' will be replaced by 'director' but with inverted logic
>> * 'bacula-nosd' will be replaced by 'storage-daemon' (also inverted).
>>
>> 'director' and 'storage-daemon' will be active by default resulting in an
>> installation with backup director and storage daemon enabled.
>>

++

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

Omit the first if we always want the client.  I don't see the need for
a "clientonly" flag if each of the two server components already have
their own flags.  If somebody doesn't want to have to know what each
of the components do they probably shouldn't be messing around with
Bacula as it is anything but install-and-forget.

-- 
Rich

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[tomjbe]

Quoting Rich Freeman (2017-08-15 00:29:19)
> On Mon, Aug 14, 2017 at 5:55 PM, Michał Górny <mgorny@gentoo.org> wrote:
> > On pon, 2017-08-14 at 21:58 +0200, Thomas Beierlein wrote:
> >>
> >> * 'bacula-clientonly' becomes 'clientonly'
> >
> > This is still negative logic in disguise. clientonly = noserver.

True. See below for discussion.
> >
> >> * 'bacula-nodir' will be replaced by 'director' but with inverted logic
> >> * 'bacula-nosd' will be replaced by 'storage-daemon' (also inverted).
> >>
> >> 'director' and 'storage-daemon' will be active by default resulting in an
> >> installation with backup director and storage daemon enabled.
> >>
> 
> ++
> 
> 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?

The downside of that idea is that we diverge from baculas documentation which
explicitly state that there is a 'clientonly' install. 

Thomas.

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2260 bytes --]

On wto, 2017-08-15 at 06:55 +0200, tomjbe@gentoo.org wrote:
> Quoting Rich Freeman (2017-08-15 00:29:19)
> > On Mon, Aug 14, 2017 at 5:55 PM, Michał Górny <mgorny@gentoo.org> wrote:
> > > On pon, 2017-08-14 at 21:58 +0200, Thomas Beierlein wrote:
> > > > 
> > > > * 'bacula-clientonly' becomes 'clientonly'
> > > 
> > > This is still negative logic in disguise. clientonly = noserver.
> 
> True. See below for discussion.
> > > 
> > > > * 'bacula-nodir' will be replaced by 'director' but with inverted logic
> > > > * 'bacula-nosd' will be replaced by 'storage-daemon' (also inverted).
> > > > 
> > > > 'director' and 'storage-daemon' will be active by default resulting in an
> > > > installation with backup director and storage daemon enabled.
> > > > 
> > 
> > ++
> > 
> > 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.

> 
> 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.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 988 bytes --]

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[tomjbe]

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)
> > > On Mon, Aug 14, 2017 at 5:55 PM, Michał Górny <mgorny@gentoo.org> wrote:
> > > > On pon, 2017-08-14 at 21:58 +0200, Thomas Beierlein wrote:
> > > > > 
> > > > > * 'bacula-clientonly' becomes 'clientonly'
> > > > 
> > > > This is still negative logic in disguise. clientonly = noserver.
> > 
> > True. See below for discussion.
> > > > 
> > > > > * 'bacula-nodir' will be replaced by 'director' but with inverted logic
> > > > > * 'bacula-nosd' will be replaced by 'storage-daemon' (also inverted).
> > > > > 
> > > > > 'director' and 'storage-daemon' will be active by default resulting in an
> > > > > installation with backup director and storage daemon enabled.
> > > > > 
> > > 
> > > ++
> > > 
> > > 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.

> > 
> > 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.

Regards,

    Thomas

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[Rich Freeman]

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.

>
>> >
>> > 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.

-- 
Rich

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[tomjbe]

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

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 391 bytes --]

On 15/08/17 18:49, tomjbe@gentoo.org wrote:
> 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
>
>
s/additional to the default file daemon.//

MJE


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 862 bytes --]

[gentoo-dev] Re: [FRC] News item: Changing USE flags for >=app-backup/bacula

[Duncan]

tomjbe posted on Tue, 15 Aug 2017 19:49:33 +0200 as excerpted:

>  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

FWIW, "additional to" is understandable, but AFAIK nonstandard (sounds 
like ESL/English-as-a-second-language, using grammar from the first).

The phrase "in addition to" works much better to my eye/ear.

Or just use "plus", if "in addition to" makes it too long...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [FRC] News item: Changing USE flags for >=app-backup/bacula

[tomjbe]

Quoting Duncan (2017-08-16 03:45:35)
> tomjbe posted on Tue, 15 Aug 2017 19:49:33 +0200 as excerpted:
> 
> >  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
> 
> FWIW, "additional to" is understandable, but AFAIK nonstandard (sounds 
> like ESL/English-as-a-second-language, using grammar from the first).
> 
> The phrase "in addition to" works much better to my eye/ear.
> 
Thanks for the hint. I was not sure which one is better.

Thomas.

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 499 bytes --]

On 08/15/2017 12:29 AM, Rich Freeman wrote:
> On Mon, Aug 14, 2017 at 5:55 PM, Michał Górny <mgorny@gentoo.org> wrote:
>> On pon, 2017-08-14 at 21:58 +0200, Thomas Beierlein wrote:
>>> * 'bacula-clientonly' becomes 'clientonly'
>> This is still negative logic in disguise. clientonly = noserver.

Can the "minimum"-use flag be utilized here?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[tomjbe]

Quoting Kristian Fiskerstrand (2017-08-15 10:37:39)
> On 08/15/2017 12:29 AM, Rich Freeman wrote:
> > On Mon, Aug 14, 2017 at 5:55 PM, Michał Górny <mgorny@gentoo.org> wrote:
> >> On pon, 2017-08-14 at 21:58 +0200, Thomas Beierlein wrote:
> >>> * 'bacula-clientonly' becomes 'clientonly'
> >> This is still negative logic in disguise. clientonly = noserver.
> 
> Can the "minimum"-use flag be utilized here?
>
Sounds reasonable and is worth thinking about. At least we could define the
meaning of "minimum" here in metadata.xml.

But, looking through portage there seems to be no "minimum" use flag anymore.
Seems it got dropped for some reasons.

Regards,

    Thomas

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 900 bytes --]

On 08/15/2017 11:33 AM, tomjbe@gentoo.org wrote:
> Quoting Kristian Fiskerstrand (2017-08-15 10:37:39)
>> On 08/15/2017 12:29 AM, Rich Freeman wrote:
>>> On Mon, Aug 14, 2017 at 5:55 PM, Michał Górny <mgorny@gentoo.org> wrote:
>>>> On pon, 2017-08-14 at 21:58 +0200, Thomas Beierlein wrote:
>>>>> * 'bacula-clientonly' becomes 'clientonly'
>>>> This is still negative logic in disguise. clientonly = noserver.
>>
>> Can the "minimum"-use flag be utilized here?
>>
> Sounds reasonable and is worth thinking about. At least we could define the
> meaning of "minimum" here in metadata.xml.
> 
> But, looking through portage there seems to be no "minimum" use flag anymore.
> Seems it got dropped for some reasons.
> 

typo; "minimal"...
-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[Rich Freeman]

On Tue, Aug 15, 2017 at 5:45 AM, Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> On 08/15/2017 11:33 AM, tomjbe@gentoo.org wrote:
>> Quoting Kristian Fiskerstrand (2017-08-15 10:37:39)
>>> On 08/15/2017 12:29 AM, Rich Freeman wrote:
>>>> On Mon, Aug 14, 2017 at 5:55 PM, Michał Górny <mgorny@gentoo.org> wrote:
>>>>> On pon, 2017-08-14 at 21:58 +0200, Thomas Beierlein wrote:
>>>>>> * 'bacula-clientonly' becomes 'clientonly'
>>>>> This is still negative logic in disguise. clientonly = noserver.
>>>
>>> Can the "minimum"-use flag be utilized here?
>>>
>> Sounds reasonable and is worth thinking about. At least we could define the
>> meaning of "minimum" here in metadata.xml.
>>
>> But, looking through portage there seems to be no "minimum" use flag anymore.
>> Seems it got dropped for some reasons.
>>
>
> typo; "minimal"...

The meaning of the minimal flag varies considerably throughout the
tree.  It is common only because its meaning morphs from package to
package.

For example, could you say that a client-only install that still
installs the X11 components is "minimal?"

-- 
Rich

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 813 bytes --]

On 08/15/2017 02:21 PM, Rich Freeman wrote:
> For example, could you say that a client-only install that still
> installs the X11 components is "minimal?"

Its somewhat context dependent, for an X application this doesn't
necessarily constitute additional dependencies for the system (think
desktop profile), whereby an application that is primarily used on
servers suddenly needing some graphics processing dragging it in is
likely wrong.

That said, the use flag description isn't more detailed than "minimal -
Install a very minimal build (disables, for example, plugins, fonts,
most drivers, non-critical features)", so I'd say it is appropriate


-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[Rich Freeman]

On Tue, Aug 15, 2017 at 6:25 AM, Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> On 08/15/2017 02:21 PM, Rich Freeman wrote:
>> For example, could you say that a client-only install that still
>> installs the X11 components is "minimal?"
>
> Its somewhat context dependent, for an X application this doesn't
> necessarily constitute additional dependencies for the system (think
> desktop profile), whereby an application that is primarily used on
> servers suddenly needing some graphics processing dragging it in is
> likely wrong.
>
> That said, the use flag description isn't more detailed than "minimal -
> Install a very minimal build (disables, for example, plugins, fonts,
> most drivers, non-critical features)", so I'd say it is appropriate
>

I'm not actually sure what you're advocating here.

My suggestion is to avoid minimal entirely, because for a package like
this it is just going to be confusing because there are so many
different optional features and disabling any of them could be
situational.  It is probably also worth nothing that minimal is itself
a negative flag.  I really question whether we ought to have it at
all.

If you're suggesting to use minimal for bacula, then what specifically
should it actually enable/disable in this particular case?

For reference, the current IUSE is:
IUSE="acl bacula-clientonly bacula-nodir bacula-nosd examples ipv6
libressl logwatch mysql postgres qt4 readline +sqlite ssl static tcpd
vim-syntax X"

There are a lot of features one might debate toggling with "minimal"
in that list.

-- 
Rich

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[tomjbe]

Quoting Thomas Beierlein (2017-08-14 21:58:42)
> Bacula ebuilds uses some weird USE flags with mostly negative
> logic ('do not build ..') coming from their build system.
> 
> With the actual major release (bacula-9.0.3) we should try to switch to
> something more sane. I picked up the new flags from app-backup/bareos as
> both ebuilds have a common anchestry.
> 
> Please comment on the proposed news item. 
> 
> Thanks,
>         Thomas
> 
First thanks to all who commented and gave wise advices.

As I see it the discussion boils down to the following new behaviour:

* There will be two USE flags 'director' and 'storage-daemon' which are on by
  default and control the installation of the backup director component 
  and the storage daemon accordingly.
* If both flags are unset neither component gets installed. Only the set of
  files for the file daemon (Client) gets installed - mimicking the
  former 'clientonly' behaviour. The old 'bacula-clientonly' flag gets dropped
  completely.
 
It will require quite some changes to the ebuild and due to its complexity
also some tests. As I have only three days left to holiday I will suspend the
switch to the new USE flag settings for now.

To let users no longer wait for the actual 9.0.3 version (which is out for
already 2 weeks now) I would like to bring it into the tree with the old USE
flag settings. The switch to the new one will then be made after returning 
from my holiday vacation.

Comments?

Best regards,

    Thomas.