[Slackbuilds-users] Optional dependencies in info file

Mon Nov 30 16:39:32 UTC 2015

On 30/11/15 17:05, JK Wood wrote:
>
> On Nov 30, 2015 4:44 AM, "Andrzej Telszewski" <atelszewski at gmail.com
> <mailto: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
> <mailto: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
> <mailto: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.

Agreed.

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

Like many of us.

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

I report the problem or suggest features in the place where I think it's 
appropriate and here we are. I don't think SBo list was a bad choice to 
discuss my idea.

We were discussing here addition of a future and I think it's perfectly 
fine place to do that. You on the other side seem to be telling me what 
should I do, which I don't like. I don't think I have abused the public 
mailing list.

>
> --JK
>
>
>
> _______________________________________________
> 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/
>

-- 
Best regards,
Andrzej Telszewski