Re: [Slackbuilds-users] Optional dependencies in info file

[Didier Spaier]

On 30/11/2015 10:13, Andrzej Telszewski wrote:
> On 30/11/15 00:31, Christoph Willing wrote:
>> On 11/30/2015 09:11 AM, Andrzej Telszewski wrote:
>>> On 29/11/15 23:56, Christoph Willing wrote:
 The only work is adding the options you want but that is also the
 advantage - you have the options _you_ want rather some some arbitrary
 set of options the maintainer wants or believes end users will want.
>>>
>>> Actually, it's like that at the moment and it always will be like that.
>>> I mean you will always have some choices that you can or not adjust to
>>> your needs.
>>>
>>> The difference is that "optional options" are mentioned in README,
>>> whereas "required options" are placed in info - you put the optional
>>> deps in *.info, which gives the whole thing better structure.
>>>
>>> But it is always *YOU* who has to make the choice, the difference is how
>>> the information about possible dependencies is given to you.
>>
>> We need to bear in mind the difference between options and dependencies.
>> An added option may, or may not, entail an added build dependency i.e.
>> any added ENVOPTS (or whatever) field _may_ need adjustment to the
>> REQUIRED field too. In order to keep existing .info fields pristine, I
>> use an additional PREREQS field to keep track of additional
>> dependencies, leaving the REQUIRED field intact.
>
> I think we understand each other, it's just wording that's awkward.
>
> I would see it more less (without longer thinking) like that:
> - additional file for optional dependencies, together with the
> environment variable (if applicable),
> - additional file for environment variables that do not require software
> dependency.
>
> That would require at least 2 things:
> - forcing SlackBuild-s creators to use the particular structure - that's
> not a problem, because SBo already has some requirements,
Good luck to get that done, but do not hold your breath.

> - making the website processing additional information to display it to
> the user; it's important, because it would be error prone to expect the
> SlackBuild creator to maintain README and additional meta-data files in
> sync.
I will let the website maintainers and admins answer that.

I am reluctant.
_ If a dependency is optional it's up to a human being to take or refuse it.
_ We have already a lot of (I almost wrote "too many") package managers, as
  listed by David (thanks again for the list):
http://idlemoor.github.io/slackrepo/links.html
  It would take a lot of time to modify all of them accordingly.
_ Along the time package managers naturally tend to provide more and more
  features less and less useful, that just complicate their usage and
  sometimes introduce bugs.
_ Some features, although they be useful, exist since a long time and come
  handy, are probably not used by many folks, like editing a SlackBuild or
  a .info from sbopkg. The more features, the more time needed by end users
  to use them.
_ It is not that difficult to list optional dependencies in a SlackBuild
  if the target audience is human beings, not computer propgrams.
  This is just an example:
http://slackbuilds.org/repository/14.1/misc/po4a/

> Still, is it worth?
No, IMHO.

I hope that this negative answer will not discourage you. We do need folks
to make proposals, be they accepted or not, so thanks for this one Andrzej.

Bien cordialement.
Best regards,
Pozdrawiam.

Didier
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/

Re: [Slackbuilds-users] Optional dependencies in info file

[JK Wood]

On Nov 30, 2015 4:44 AM, "Andrzej Telszewski"  wrote:
>
> On 30/11/15 11:13, Didier Spaier wrote:
>>
>> On 30/11/2015 10:13, Andrzej Telszewski wrote:
>>>
>>> On 30/11/15 00:31, Christoph Willing wrote:

 On 11/30/2015 09:11 AM, Andrzej Telszewski wrote:
>
> On 29/11/15 23:56, Christoph Willing wrote:
>>
>> The only work is adding the options you want but that is also the
>> advantage - you have the options _you_ want rather some some
arbitrary
>> set of options the maintainer wants or believes end users will want.
>
>
> Actually, it's like that at the moment and it always will be like
that.
> I mean you will always have some choices that you can or not adjust to
> your needs.
>
> The difference is that "optional options" are mentioned in README,
> whereas "required options" are placed in info - you put the optional
> deps in *.info, which gives the whole thing better structure.
>
> But it is always *YOU* who has to make the choice, the difference is
how
> the information about possible dependencies is given to you.


 We need to bear in mind the difference between options and
dependencies.
 An added option may, or may not, entail an added build dependency i.e.
 any added ENVOPTS (or whatever) field _may_ need adjustment to the
 REQUIRED field too. In order to keep existing .info fields pristine, I
 use an additional PREREQS field to keep track of additional
 dependencies, leaving the REQUIRED field intact.
>>>
>>>
>>> I think we understand each other, it's just wording that's awkward.
>>>
>>> I would see it more less (without longer thinking) like that:
>>> - additional file for optional dependencies, together with the
>>> environment variable (if applicable),
>>> - additional file for environment variables that do not require software
>>> dependency.
>>>
>>> That would require at least 2 things:
>>> - forcing SlackBuild-s creators to use the particular structure - that's
>>> not a problem, because SBo already has some requirements,
>>
>> Good luck to get that done, but do not hold your breath.
>>
>>> - making the website processing additional information to display it to
>>> the user; it's important, because it would be error prone to expect the
>>> SlackBuild creator to maintain README and additional meta-data files in
>>> sync.
>>
>> I will let the website maintainers and admins answer that.
>>
>> I am reluctant.
>> _ If a dependency is optional it's up to a human being to take or refuse
it.
>> _ We have already a lot of (I almost wrote "too many") package managers,
as
>>listed by David (thanks again for the list):
>>  http://idlemoor.github.io/slackrepo/links.html
>>It would take a lot of time to modify all of them accordingly.
>> _ Along the time package managers naturally tend to provide more and more
>>features less and less useful, that just complicate their usage and
>>sometimes introduce bugs.
>> _ Some features, although they be useful, exist since a long time and
come
>>handy, are probably not used by many folks, like editing a SlackBuild
or
>>a .info from sbopkg. The more features, the more time needed by end
users
>>to use them.
>> _ It is not that difficult to list optional dependencies in a SlackBuild
>>if the target audience is human beings, not computer propgrams.
>>This is just an example:
>>  http://slackbuilds.org/repository/14.1/misc/po4a/
>>
>>> Still, is it worth?
>>
>> No, IMHO.
>
>
> Well, I too think that it would be much work, it's probably not worth it.
>
> What is your opinion on the READMEs? For me it was the culprit, that made
me propose what I've proposed. It's my personal opinion, but the READMEs
are not well readable;)
>
> I would propose to allow markdown in READMEs, but still, the maintainers
would have to use it in consistent way.
>
> I know one should read the READMEs thoroughly, but it's much easier to
spot what's important, if it's *for example in bold*.
>
> Like any other well written software, SBo deserves good documentation:)
>
> I don't think we'll go much further with that for a moment;)
>
>
>>
>> I hope that this negative answer will not discourage you. We do need
folks
>> to make proposals, be they accepted or not, so thanks for this one
Andrzej.
>
>
> No worries:)
>
>
>>
>> Bien cordialement.
>> Best regards,
>> Pozdrawiam.
>
>
> Saludos cordiales:)
>
>
>>
>> Didier
>> ___
>> SlackBuilds-users mailing list
>> SlackBuilds-users@slackbuilds.org
>> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
>> FAQ - http://slackbuilds.org/faq/
>>
>>
>
>
> --
> Pozdrawiam,
> Best regards,
> Andrzej Telszewski
> ___
> SlackBuilds-users mailing list
> SlackBuilds-users@slackbuilds.org
> 

Re: [Slackbuilds-users] Optional dependencies in info file

[Andrzej Telszewski]

On 30/11/15 11:13, Didier Spaier wrote:

On 30/11/2015 10:13, Andrzej Telszewski wrote:

On 30/11/15 00:31, Christoph Willing wrote:

On 11/30/2015 09:11 AM, Andrzej Telszewski wrote:

On 29/11/15 23:56, Christoph Willing wrote:

The only work is adding the options you want but that is also the
advantage - you have the options _you_ want rather some some arbitrary
set of options the maintainer wants or believes end users will want.


Actually, it's like that at the moment and it always will be like that.
I mean you will always have some choices that you can or not adjust to
your needs.

The difference is that "optional options" are mentioned in README,
whereas "required options" are placed in info - you put the optional
deps in *.info, which gives the whole thing better structure.

But it is always *YOU* who has to make the choice, the difference is how
the information about possible dependencies is given to you.


We need to bear in mind the difference between options and dependencies.
An added option may, or may not, entail an added build dependency i.e.
any added ENVOPTS (or whatever) field _may_ need adjustment to the
REQUIRED field too. In order to keep existing .info fields pristine, I
use an additional PREREQS field to keep track of additional
dependencies, leaving the REQUIRED field intact.


I think we understand each other, it's just wording that's awkward.

I would see it more less (without longer thinking) like that:
- additional file for optional dependencies, together with the
environment variable (if applicable),
- additional file for environment variables that do not require software
dependency.

That would require at least 2 things:
- forcing SlackBuild-s creators to use the particular structure - that's
not a problem, because SBo already has some requirements,

Good luck to get that done, but do not hold your breath.


- making the website processing additional information to display it to
the user; it's important, because it would be error prone to expect the
SlackBuild creator to maintain README and additional meta-data files in
sync.

I will let the website maintainers and admins answer that.

I am reluctant.
_ If a dependency is optional it's up to a human being to take or refuse it.
_ We have already a lot of (I almost wrote "too many") package managers, as
   listed by David (thanks again for the list):
 http://idlemoor.github.io/slackrepo/links.html
   It would take a lot of time to modify all of them accordingly.
_ Along the time package managers naturally tend to provide more and more
   features less and less useful, that just complicate their usage and
   sometimes introduce bugs.
_ Some features, although they be useful, exist since a long time and come
   handy, are probably not used by many folks, like editing a SlackBuild or
   a .info from sbopkg. The more features, the more time needed by end users
   to use them.
_ It is not that difficult to list optional dependencies in a SlackBuild
   if the target audience is human beings, not computer propgrams.
   This is just an example:
 http://slackbuilds.org/repository/14.1/misc/po4a/


Still, is it worth?

No, IMHO.


Well, I too think that it would be much work, it's probably not worth it.

What is your opinion on the READMEs? For me it was the culprit, that 
made me propose what I've proposed. It's my personal opinion, but the 
READMEs are not well readable;)


I would propose to allow markdown in READMEs, but still, the maintainers 
would have to use it in consistent way.


I know one should read the READMEs thoroughly, but it's much easier to 
spot what's important, if it's *for example in bold*.


Like any other well written software, SBo deserves good documentation:)

I don't think we'll go much further with that for a moment;)



I hope that this negative answer will not discourage you. We do need folks
to make proposals, be they accepted or not, so thanks for this one Andrzej.


No worries:)



Bien cordialement.
Best regards,
Pozdrawiam.


Saludos cordiales:)



Didier
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/





--
Pozdrawiam,
Best regards,
Andrzej Telszewski
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/

Re: [Slackbuilds-users] Optional dependencies in info file

[Andrzej Telszewski]

On 30/11/15 00:31, Christoph Willing wrote:

On 11/30/2015 09:11 AM, Andrzej Telszewski wrote:

On 29/11/15 23:56, Christoph Willing wrote:

The only work is adding the options you want but that is also the
advantage - you have the options _you_ want rather some some arbitrary
set of options the maintainer wants or believes end users will want.


Actually, it's like that at the moment and it always will be like that.
I mean you will always have some choices that you can or not adjust to
your needs.

The difference is that "optional options" are mentioned in README,
whereas "required options" are placed in info - you put the optional
deps in *.info, which gives the whole thing better structure.

But it is always *YOU* who has to make the choice, the difference is how
the information about possible dependencies is given to you.


We need to bear in mind the difference between options and dependencies.
An added option may, or may not, entail an added build dependency i.e.
any added ENVOPTS (or whatever) field _may_ need adjustment to the
REQUIRED field too. In order to keep existing .info fields pristine, I
use an additional PREREQS field to keep track of additional
dependencies, leaving the REQUIRED field intact.


I think we understand each other, it's just wording that's awkward.

I would see it more less (without longer thinking) like that:
- additional file for optional dependencies, together with the 
environment variable (if applicable),
- additional file for environment variables that do not require software 
dependency.


That would require at least 2 things:
- forcing SlackBuild-s creators to use the particular structure - that's 
not a problem, because SBo already has some requirements,
- making the website processing additional information to display it to 
the user; it's important, because it would be error prone to expect the 
SlackBuild creator to maintain README and additional meta-data files in 
sync.



Still, is it worth? (Willy, I can here your voice behind my back:))



chris

___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/





--
Pozdrawiam,
Best regards,
Andrzej Telszewski
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/

Re: [Slackbuilds-users] Optional dependencies in info file

[Andrzej Telszewski]

On 29/11/15 17:56, Willy Sudiarto Raharjo wrote:

What do you think about putting optional (available from SBo)
dependencies in the info file?
I think that would allow for further automation.

What I have noticed is that, it's sometimes hard to go through the
README and spot all the optional deps, because everybody writes README
as she/he sees fit.

Also, I don't know how, but it could be possibly worth if all the
variables (like ENABLE_FOO=yes, DISABLE_BAR=no) could be gathered in one
well structured place.

This thoughts came to me when I wanted to build 'ffmpeg'. Well, not all
of those thoughts, because SlackBuild for 'ffmpeg' is actually well
written.

But if some more rigid structure, possibly easily understood by
computers, was enforced, it could make users' life easier.

What do you think?


It's really up to the maintainer to set which deps should go into
REQUIRES since he/she is the one knows best about it. We only make sure
that it builds normally with all the deps mentioned on the README.

my personal thought:
I like to keep the packages minimum and list all the optional ones in
the README. I don't want to have a bloated systems with all deps are
listed just to satisfy minor functionality


Well, your the boss;)

What do you mean by bloated system? If the optional deps are placed in 
the info file, then automated tools can benefit from that. It's still up 
to the user to decide if she wants them.


Putting optional deps in info makes just for easier processing, I don't 
see any possibility of bloating here.


And SBo maintainers could declare that optional deps are not tested.

What do you think?






___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/




--
Pozdrawiam,
Best regards,
Andrzej Telszewski
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/

Re: [Slackbuilds-users] Optional dependencies in info file

[Brenton Earl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


This would require that package managers be added the feature that
enables them to look at the optional line as well.  They would need to
have the ability to ask if the optional dependencies are added and
which specific deps depending on which features are required.
Furthermore, the package managers would need to know how to switch on
those features or the SlackBuilds would need to have an additonal hook
that tells the package manager what to do with those optional deps.

On 11/29/2015 10:45 AM, Andrzej Telszewski wrote:
> On 29/11/15 18:41, Petar Petrov wrote:
>> do you suggest that all dependencies are listed in the REQUIRES
>> field or that there is a new field eg OPTIONAL introduced?
>> 
>> for example in case of EMBOSS:
>> 
>> REQUIRES="jdk"
>> 
>> OPTIONAL="clustalw primer3"
>> 
>> 
>> On 29/11/15 17:56, Willy Sudiarto Raharjo wrote:
>> 
>> What do you think about putting optional (available from SBo) 
>> dependencies in the info file? I think that would allow for
>> further automation.
>> 
>> What I have noticed is that, it's sometimes hard to go through
>> the README and spot all the optional deps, because everybody 
>> writes README as she/he sees fit.
>> 
>> Also, I don't know how, but it could be possibly worth if all
>> the variables (like ENABLE_FOO=yes, DISABLE_BAR=no) could be 
>> gathered in one well structured place.
>> 
>> This thoughts came to me when I wanted to build 'ffmpeg'. Well,
>> not all of those thoughts, because SlackBuild for 'ffmpeg' is 
>> actually well written.
>> 
>> But if some more rigid structure, possibly easily understood by 
>> computers, was enforced, it could make users' life easier.
>> 
>> What do you think?
>> 
>> 
>> It's really up to the maintainer to set which deps should go
>> into REQUIRES since he/she is the one knows best about it. We
>> only make sure that it builds normally with all the deps
>> mentioned on the README.
>> 
>> my personal thought: I like to keep the packages minimum and list
>> all the optional ones in the README. I don't want to have a
>> bloated systems with all deps are listed just to satisfy minor
>> functionality
>> 
>> 
>> Well, your the boss;)
>> 
>> What do you mean by bloated system? If the optional deps are
>> placed in the info file, then automated tools can benefit from
>> that. It's still up to the user to decide if she wants them.
>> 
>> Putting optional deps in info makes just for easier processing,
>> I don't see any possibility of bloating here.
>> 
>> And SBo maintainers could declare that optional deps are not
>> tested.
>> 
>> What do you think?
>> 
> 
> I meant something like OPTIONAL="clustalw primer3".
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWWzs+AAoJEMAWbOXyIOfznxEH/AkRAMz1mmYLs8EeuWT3j7Tn
+5a6KUPv/+s7kOKqZoY63OHsDBMljqE+MYH3YCLrJQxdjw4HbQN3rvi9G5er8fgF
D4xcwlSgpdTAIEziANvuJXTJYggJwfmM29inWWswGyXKtbNwic6qkfoS3r2V9Ooe
+XfdE198k6pRPOItg6wgVFgOFgug+mwKif6S+MfvvHFWjLHScBppOspExoN9KKm6
Gw6GswwVmZRZ5CY0ZkSCRuXIEQh7x06F/ArfT+oTRm3pRN4MqQ8k9VpLxdyilrk2
5uxcBIpuj50bfRIY71GEyssX81RBlXdCCwje7xwXani1bK8KDyRzevY15Hmzk6Y=
=b+er
-END PGP SIGNATURE-
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/

Re: [Slackbuilds-users] Optional dependencies in info file

[Andrzej Telszewski]

On 29/11/15 18:51, Brenton Earl wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


This would require that package managers be added the feature that
enables them to look at the optional line as well.  They would need to
have the ability to ask if the optional dependencies are added and
which specific deps depending on which features are required.
Furthermore, the package managers would need to know how to switch on
those features or the SlackBuilds would need to have an additonal hook
that tells the package manager what to do with those optional deps.

On 11/29/2015 10:45 AM, Andrzej Telszewski wrote:

On 29/11/15 18:41, Petar Petrov wrote:

do you suggest that all dependencies are listed in the REQUIRES
field or that there is a new field eg OPTIONAL introduced?

for example in case of EMBOSS:

REQUIRES="jdk"

OPTIONAL="clustalw primer3"


On 29/11/15 17:56, Willy Sudiarto Raharjo wrote:

What do you think about putting optional (available from SBo)
dependencies in the info file? I think that would allow for
further automation.

What I have noticed is that, it's sometimes hard to go through
the README and spot all the optional deps, because everybody
writes README as she/he sees fit.

Also, I don't know how, but it could be possibly worth if all
the variables (like ENABLE_FOO=yes, DISABLE_BAR=no) could be
gathered in one well structured place.

This thoughts came to me when I wanted to build 'ffmpeg'. Well,
not all of those thoughts, because SlackBuild for 'ffmpeg' is
actually well written.

But if some more rigid structure, possibly easily understood by
computers, was enforced, it could make users' life easier.

What do you think?


It's really up to the maintainer to set which deps should go
into REQUIRES since he/she is the one knows best about it. We
only make sure that it builds normally with all the deps
mentioned on the README.

my personal thought: I like to keep the packages minimum and list
all the optional ones in the README. I don't want to have a
bloated systems with all deps are listed just to satisfy minor
functionality


Well, your the boss;)

What do you mean by bloated system? If the optional deps are
placed in the info file, then automated tools can benefit from
that. It's still up to the user to decide if she wants them.

Putting optional deps in info makes just for easier processing,
I don't see any possibility of bloating here.

And SBo maintainers could declare that optional deps are not
tested.

What do you think?



I meant something like OPTIONAL="clustalw primer3".


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWWzs+AAoJEMAWbOXyIOfznxEH/AkRAMz1mmYLs8EeuWT3j7Tn
+5a6KUPv/+s7kOKqZoY63OHsDBMljqE+MYH3YCLrJQxdjw4HbQN3rvi9G5er8fgF
D4xcwlSgpdTAIEziANvuJXTJYggJwfmM29inWWswGyXKtbNwic6qkfoS3r2V9Ooe
+XfdE198k6pRPOItg6wgVFgOFgug+mwKif6S+MfvvHFWjLHScBppOspExoN9KKm6
Gw6GswwVmZRZ5CY0ZkSCRuXIEQh7x06F/ArfT+oTRm3pRN4MqQ8k9VpLxdyilrk2
5uxcBIpuj50bfRIY71GEyssX81RBlXdCCwje7xwXani1bK8KDyRzevY15Hmzk6Y=
=b+er
-END PGP SIGNATURE-
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/




For the moment I thought that we could use something similar to Linux 
kernel kconfig for additional options.


The point is, I guess in almost all of the cases we could have a well 
structured system, but initial effort would quite high and I don't know 
if it's worth.


I think that after the transition, the maintenance cost wouldn't be much 
bigger. If, instead of plain text README, the website would parse all 
the structured configs, then there would be nothing to do.


Also, well structured system is easier to check in automated fashion.

--
Pozdrawiam,
Best regards,
Andrzej Telszewski
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/

Re: [Slackbuilds-users] Optional dependencies in info file

[Matteo Bernardini]

2015-11-29 18:10 GMT+01:00 Andrzej Telszewski :
> On 29/11/15 17:56, Willy Sudiarto Raharjo wrote:
>>>
>>> What do you think about putting optional (available from SBo)
>>> dependencies in the info file?
>>> I think that would allow for further automation.
>>>
>>> What I have noticed is that, it's sometimes hard to go through the
>>> README and spot all the optional deps, because everybody writes README
>>> as she/he sees fit.
>>>
>>> Also, I don't know how, but it could be possibly worth if all the
>>> variables (like ENABLE_FOO=yes, DISABLE_BAR=no) could be gathered in one
>>> well structured place.
>>>
>>> This thoughts came to me when I wanted to build 'ffmpeg'. Well, not all
>>> of those thoughts, because SlackBuild for 'ffmpeg' is actually well
>>> written.
>>>
>>> But if some more rigid structure, possibly easily understood by
>>> computers, was enforced, it could make users' life easier.
>>>
>>> What do you think?
>>
>>
>> It's really up to the maintainer to set which deps should go into
>> REQUIRES since he/she is the one knows best about it. We only make sure
>> that it builds normally with all the deps mentioned on the README.
>>
>> my personal thought:
>> I like to keep the packages minimum and list all the optional ones in
>> the README. I don't want to have a bloated systems with all deps are
>> listed just to satisfy minor functionality
>
>
> Well, your the boss;)
>
> What do you mean by bloated system? If the optional deps are placed in the
> info file, then automated tools can benefit from that. It's still up to the
> user to decide if she wants them.
>
> Putting optional deps in info makes just for easier processing, I don't see
> any possibility of bloating here.
>
> And SBo maintainers could declare that optional deps are not tested.
>
> What do you think?

some points that comes to mind:
- optional dependencies in the info file will require nevertheless an
explaination of what they enable and that could make the info file
messy;
- some are autodetected, some require passing the script a variable to
enable them... there's no standard and not because we doesn't want it
to be but becauseit depends on the software in question;
- everybody should read the README of whatever they build from SBo in
*any* case.

Matteo
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/

Re: [Slackbuilds-users] Optional dependencies in info file

[Andrzej Telszewski]

On 29/11/15 18:17, Matteo Bernardini wrote:

2015-11-29 18:10 GMT+01:00 Andrzej Telszewski :

On 29/11/15 17:56, Willy Sudiarto Raharjo wrote:


What do you think about putting optional (available from SBo)
dependencies in the info file?
I think that would allow for further automation.

What I have noticed is that, it's sometimes hard to go through the
README and spot all the optional deps, because everybody writes README
as she/he sees fit.

Also, I don't know how, but it could be possibly worth if all the
variables (like ENABLE_FOO=yes, DISABLE_BAR=no) could be gathered in one
well structured place.

This thoughts came to me when I wanted to build 'ffmpeg'. Well, not all
of those thoughts, because SlackBuild for 'ffmpeg' is actually well
written.

But if some more rigid structure, possibly easily understood by
computers, was enforced, it could make users' life easier.

What do you think?



It's really up to the maintainer to set which deps should go into
REQUIRES since he/she is the one knows best about it. We only make sure
that it builds normally with all the deps mentioned on the README.

my personal thought:
I like to keep the packages minimum and list all the optional ones in
the README. I don't want to have a bloated systems with all deps are
listed just to satisfy minor functionality



Well, your the boss;)

What do you mean by bloated system? If the optional deps are placed in the
info file, then automated tools can benefit from that. It's still up to the
user to decide if she wants them.

Putting optional deps in info makes just for easier processing, I don't see
any possibility of bloating here.

And SBo maintainers could declare that optional deps are not tested.

What do you think?


some points that comes to mind:
- optional dependencies in the info file will require nevertheless an
explaination of what they enable and that could make the info file
messy;
- some are autodetected, some require passing the script a variable to
enable them... there's no standard and not because we doesn't want it
to be but becauseit depends on the software in question;
- everybody should read the README of whatever they build from SBo in
*any* case.


OK, forget it. It would be too much work over little benefit.

Now I would just vote for better, that is more structured READMEs.
But that too might be only me who has the feeling that the READMEs 
aren't as good as they should be.




Matteo
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/





--
Pozdrawiam,
Best regards,
Andrzej Telszewski
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/

Re: [Slackbuilds-users] Optional dependencies in info file

[Willy Sudiarto Raharjo]

> What do you think about putting optional (available from SBo)
> dependencies in the info file?
> I think that would allow for further automation.
> 
> What I have noticed is that, it's sometimes hard to go through the
> README and spot all the optional deps, because everybody writes README
> as she/he sees fit.
> 
> Also, I don't know how, but it could be possibly worth if all the
> variables (like ENABLE_FOO=yes, DISABLE_BAR=no) could be gathered in one
> well structured place.
> 
> This thoughts came to me when I wanted to build 'ffmpeg'. Well, not all
> of those thoughts, because SlackBuild for 'ffmpeg' is actually well
> written.
> 
> But if some more rigid structure, possibly easily understood by
> computers, was enforced, it could make users' life easier.
> 
> What do you think?

It's really up to the maintainer to set which deps should go into
REQUIRES since he/she is the one knows best about it. We only make sure
that it builds normally with all the deps mentioned on the README.

my personal thought:
I like to keep the packages minimum and list all the optional ones in
the README. I don't want to have a bloated systems with all deps are
listed just to satisfy minor functionality


-- 
Willy Sudiarto Raharjo



signature.asc
Description: OpenPGP digital signature
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/

Re: [Slackbuilds-users] Optional dependencies in info file

[Christoph Willing]

One of the nice things about the .info files is that just about anything 
can be added to them; automated build tools will generally ignore any 
new fields you may choose to add. From my clone of the SBo repo, I have 
a branch named "spbuilder" (after the name of the build tool I use). In 
that branch I make any modifications that I want, in particular the 
addition of an ENVOPTS field in which I place any environment variables 
I want exported before building. For instance my ffmpeg.info has:


ENVOPTS="LAME=yes X264=yes CELT=yes DC1394=yes FREI0R=yes GSM=yes 
RTMP=yes SCHROEDINGER=yes SPEEX=yes VPX=yes XVID=yes BLURAY=yes ASS=yes 
OPENAL=yes IEC61883=yes ILBC=yes MODPLUG=yes OPUS=yes TWOLAME=yes 
LADSPA=yes PULSEAUDIO=yes X265=yes ZVBI=yes OPENCORE=yes FAAC=yes 
OPENSSL=yes DECKLINK=yes

"

I use this as example as it demonstrates exactly the sort of thing I 
don't want to have to remember when I build ffmpeg. I could keep a note 
about it  somewhere -  how about as an ENVOPTS field in the .info file?


Another sometimes useful option is ENVOPTS="MAKEFLAGS=-j1".

Since each build is done in a new container, there's no problem with 
polluting the environment for future builds. That said, I have sometimes 
used a qemu or vbox VM to build an app and all its dependencies and I 
didn't find environment pollution due to multiple exports of the 
different ENVOPTS to be a problem.


The only work is adding the options you want but that is also the 
advantage - you have the options _you_ want rather some some arbitrary 
set of options the maintainer wants or believes end users will want. 
Naturally not all SlackBuilds need any options set so the number of 
changes is actually quite small (I have 9 modified out of the 434 that I 
have builds of), so the amount of work for an individual is quite low.


Of course it will need support by build tools to be useful. Luckily I 
have my own build tool that supports it. If the recognised tools won't
support it, fork one of them and add such support yourself - the general 
idea is just to just export the ENVOPTS field immediately before the 
.SlackBuild is run (at least after the .info file is sourced or parsed). 
I guess more complete support could include unsetting each of the added 
options after each build.


Lastly, ENVOPTS was just my choice of name - you can name it whatever 
you like.


chris

___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/

Re: [Slackbuilds-users] Optional dependencies in info file

[Andrzej Telszewski]

On 29/11/15 23:56, Christoph Willing wrote:

The only work is adding the options you want but that is also the
advantage - you have the options _you_ want rather some some arbitrary
set of options the maintainer wants or believes end users will want.


Actually, it's like that at the moment and it always will be like that.
I mean you will always have some choices that you can or not adjust to 
your needs.


The difference is that "optional options" are mentioned in README, 
whereas "required options" are placed in info - you put the optional 
deps in *.info, which gives the whole thing better structure.


But it is always *YOU* who has to make the choice, the difference is how 
the information about possible dependencies is given to you.


--
Pozdrawiam,
Best regards,
Andrzej Telszewski
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/

Re: [Slackbuilds-users] Optional dependencies in info file

[Willy Sudiarto Raharjo]

> do you suggest that all dependencies are listed in the REQUIRES field or
> that there is a new field eg OPTIONAL introduced?
> 
> for example in case of EMBOSS:
> 
> REQUIRES="jdk"
> 
> OPTIONAL="clustalw primer3"

That will make maintainer and admin's job becomes more complicated :)


-- 
Willy Sudiarto Raharjo



signature.asc
Description: OpenPGP digital signature
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/

Re: [Slackbuilds-users] Optional dependencies in info file

[Andrzej Telszewski]

On 29/11/15 18:41, Petar Petrov wrote:

do you suggest that all dependencies are listed in the REQUIRES field or
that there is a new field eg OPTIONAL introduced?

for example in case of EMBOSS:

REQUIRES="jdk"

OPTIONAL="clustalw primer3"



2015-11-29 19:10 GMT+02:00 Andrzej Telszewski >:

On 29/11/15 17:56, Willy Sudiarto Raharjo wrote:

What do you think about putting optional (available from SBo)
dependencies in the info file?
I think that would allow for further automation.

What I have noticed is that, it's sometimes hard to go
through the
README and spot all the optional deps, because everybody
writes README
as she/he sees fit.

Also, I don't know how, but it could be possibly worth if
all the
variables (like ENABLE_FOO=yes, DISABLE_BAR=no) could be
gathered in one
well structured place.

This thoughts came to me when I wanted to build 'ffmpeg'.
Well, not all
of those thoughts, because SlackBuild for 'ffmpeg' is
actually well
written.

But if some more rigid structure, possibly easily understood by
computers, was enforced, it could make users' life easier.

What do you think?


It's really up to the maintainer to set which deps should go into
REQUIRES since he/she is the one knows best about it. We only
make sure
that it builds normally with all the deps mentioned on the README.

my personal thought:
I like to keep the packages minimum and list all the optional
ones in
the README. I don't want to have a bloated systems with all deps are
listed just to satisfy minor functionality


Well, your the boss;)

What do you mean by bloated system? If the optional deps are placed
in the info file, then automated tools can benefit from that. It's
still up to the user to decide if she wants them.

Putting optional deps in info makes just for easier processing, I
don't see any possibility of bloating here.

And SBo maintainers could declare that optional deps are not tested.

What do you think?





___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org

http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/



--
Pozdrawiam,
Best regards,
Andrzej Telszewski
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org

http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/




___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/



I meant something like OPTIONAL="clustalw primer3".

--
Best regards,
Andrzej Telszewski
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/

[Slackbuilds-users] Optional dependencies in info file

[Andrzej Telszewski]

Hi,

What do you think about putting optional (available from SBo) 
dependencies in the info file?

I think that would allow for further automation.

What I have noticed is that, it's sometimes hard to go through the 
README and spot all the optional deps, because everybody writes README 
as she/he sees fit.


Also, I don't know how, but it could be possibly worth if all the 
variables (like ENABLE_FOO=yes, DISABLE_BAR=no) could be gathered in one 
well structured place.


This thoughts came to me when I wanted to build 'ffmpeg'. Well, not all 
of those thoughts, because SlackBuild for 'ffmpeg' is actually well written.


But if some more rigid structure, possibly easily understood by 
computers, was enforced, it could make users' life easier.


What do you think?

--
Best regards,
Andrzej Telszewski
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/

Re: [Slackbuilds-users] Optional dependencies in info file

[Christoph Willing]

On 11/30/2015 09:11 AM, Andrzej Telszewski wrote:

On 29/11/15 23:56, Christoph Willing wrote:

The only work is adding the options you want but that is also the
advantage - you have the options _you_ want rather some some arbitrary
set of options the maintainer wants or believes end users will want.


Actually, it's like that at the moment and it always will be like that.
I mean you will always have some choices that you can or not adjust to
your needs.

The difference is that "optional options" are mentioned in README,
whereas "required options" are placed in info - you put the optional
deps in *.info, which gives the whole thing better structure.

But it is always *YOU* who has to make the choice, the difference is how
the information about possible dependencies is given to you.


We need to bear in mind the difference between options and dependencies. 
An added option may, or may not, entail an added build dependency i.e. 
any added ENVOPTS (or whatever) field _may_ need adjustment to the 
REQUIRED field too. In order to keep existing .info fields pristine, I 
use an additional PREREQS field to keep track of additional 
dependencies, leaving the REQUIRED field intact.


chris

___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/

Re: [Slackbuilds-users] Optional dependencies in info file

[Petar Petrov]

do you suggest that all dependencies are listed in the REQUIRES field or
that there is a new field eg OPTIONAL introduced?

for example in case of EMBOSS:

REQUIRES="jdk"

OPTIONAL="clustalw primer3"



2015-11-29 19:10 GMT+02:00 Andrzej Telszewski :

> On 29/11/15 17:56, Willy Sudiarto Raharjo wrote:
>
>> What do you think about putting optional (available from SBo)
>>> dependencies in the info file?
>>> I think that would allow for further automation.
>>>
>>> What I have noticed is that, it's sometimes hard to go through the
>>> README and spot all the optional deps, because everybody writes README
>>> as she/he sees fit.
>>>
>>> Also, I don't know how, but it could be possibly worth if all the
>>> variables (like ENABLE_FOO=yes, DISABLE_BAR=no) could be gathered in one
>>> well structured place.
>>>
>>> This thoughts came to me when I wanted to build 'ffmpeg'. Well, not all
>>> of those thoughts, because SlackBuild for 'ffmpeg' is actually well
>>> written.
>>>
>>> But if some more rigid structure, possibly easily understood by
>>> computers, was enforced, it could make users' life easier.
>>>
>>> What do you think?
>>>
>>
>> It's really up to the maintainer to set which deps should go into
>> REQUIRES since he/she is the one knows best about it. We only make sure
>> that it builds normally with all the deps mentioned on the README.
>>
>> my personal thought:
>> I like to keep the packages minimum and list all the optional ones in
>> the README. I don't want to have a bloated systems with all deps are
>> listed just to satisfy minor functionality
>>
>
> Well, your the boss;)
>
> What do you mean by bloated system? If the optional deps are placed in the
> info file, then automated tools can benefit from that. It's still up to the
> user to decide if she wants them.
>
> Putting optional deps in info makes just for easier processing, I don't
> see any possibility of bloating here.
>
> And SBo maintainers could declare that optional deps are not tested.
>
> What do you think?
>
>
>>
>>
>>
>> ___
>> SlackBuilds-users mailing list
>> SlackBuilds-users@slackbuilds.org
>> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
>> FAQ - http://slackbuilds.org/faq/
>>
>>
>
> --
> Pozdrawiam,
> Best regards,
> Andrzej Telszewski
> ___
> SlackBuilds-users mailing list
> SlackBuilds-users@slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - http://slackbuilds.org/faq/
>
>
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/