[Slackbuilds-users] Plex version too old
1.41421 at gmail.com
Fri May 4 18:42:39 UTC 2018
On Fri, May 4, 2018 at 10:50 AM, Matteo Bernardini <
matteo.bernardini at gmail.com> wrote:
> 2018-05-04 18:40 GMT+02:00 JCA <1.41421 at gmail.com>:
> > Fair enough. Now make sure to enter the gist of this in the Slackbuilds
> > page, in a big font, so nobody will be led to think that packages are
> > properly maintained throughout.
> it's not that finding a limited number of not maintained SlackBuilds
> means that all of 7000 of them are unmaintained: just calculate the
> percentage and you can see they are a very small part.
The fact still remains that poorly maintained packages exist. Why not say
so, if it is true?
This aside, my own experience is that I have to massage things often to get
them to work - admittedly mostly in straightforward ways, although the
plexmediaserver fiasco is not a first. Also bear in mind that package that
has not been updated in a long time might still work, but might be missing
important patches, security upgrades and improvements. Again, something
that a good maintainer should be on top of.
> >> Meanwhile, thanks for the report.
> > Any time. My hope is that will do something to improve things for this,
> > other packages in similar situations of abandonment.
> IMHO is only maintaining stuff yourself that helps in these cases.
True. However, like I said, I, and many like me, are not interested in
maintaining, but on using. Again, this may be something frowned upon in
this forum, and not in the spirit of Slackbuilds. This would be completely
legitimate - just make it obvious in the home page that, if you want to
make sure that a package is really functional, you should maintain it
yourself, for it is neither the purview nor the responsibility of the
Slackbuilds team to guarantee that maintainers of Slackbuilds packages are
doing what they committed to do. This is what is already happening; it is
just that, as a new Slackware/Slackbuilds user, one may not be aware of
that initially. I think that not making this clear to such users amounts to
making them a disservice.
> 2018-05-04 18:44 GMT+02:00 JCA <1.41421 at gmail.com>:
> > <matteo.bernardini at gmail.com> wrote:
> >> ...and this exposes the real issue: pretty much nobody reads the
> >> READMEs or the scripts they run in the first place.
> > Precisely. Which is why I was suggesting the Slackbuilds home page, in a
> > font. In obnoxiously flashing text, if you want. That does not guarantee
> > that people will read it, but it is far more difficult to miss. This
> > that's boilerplate, legalese stuff. What matters is what can be
> > expected.
> I think you got this completely wrong: if you don't read the READMEs
> and the scripts you run, it's just your fault and you shouldn't blame
> nobody else.
And I think that you are not being realistic. Since probably the vast
majority of freely distributed software packages contain similarly-worded
disclaimers, those words mean very little. A very conspicuous warning in
the Slackware home page would command more attention. And would kill
discussions like this before they are even born, for everybody who has
visited the Slackbuilds page even once would have no choice but to see the
Just make it clear in that page that Slackbuilds is for enthusiasts, by
enthusiasts; that packages may, or may not, work; that they may, or may
not, be maintained; that the vast majority of them seem to be maintained
and work, although nothing can be guaranteed; that, if you want to make
sure, just maintain yourself the packages that you are interested in.
That's the way it is. And it may be intentional. Which would, again, be
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SlackBuilds-users