[Slackbuilds-users] Optional dependencies in info file

[JK Wood]

On Nov 30, 2015 4:44 AM, "Andrzej Telszewski" <atelszewski at gmail.com> 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 at 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 at slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - http://slackbuilds.org/faq/
>

READMEs are meant to be human readable, not to be machine readable.
Further, we expect them to not only be human readable, but also to actually
be read by humans. Markdown is fine for the web, but I read package READMEs
in vim on the command line - markdown would make that quite a bit messier.

We have few enough maintainers as it is. I provide my SlackBuilds free of
charge, without compensation, and on my own time. My intention is to
provide a good starting point from which to build and package a piece of
software. Advanced usage is up to the end user, and the onus should not be
on me to make it easier for some automated tool to facilitate that advanced
usage. I have enough problems from the software I package alone without
having more demands made on my time for very little benefit.

If you have an issue with a particular README from a particular SlackBuild,
a more productive approach would be to email that maintainer rather than
defaulting to suggesting there's a systemic problem with the way we do
things on the public mailing list.

--JK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20151130/6b1f23fc/attachment-0001.html>