[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 at 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