[Slackbuilds-users] incomplete/bad READMEs/slack-descs. thorium.SlackBuild defeats purpose

[Willy Sudiarto Raharjo]

>The Thorium web browser was created to fork Chromium to several newer 
>classes of CPUs than Chromium considers minimal (very old).  I noticed 
>thorium.SlackBuild simply repackages an arbitrary .deb, which I believe 
>repackaging .debs & .rpms are almost always a bad way to do things, 
>despite some SlackBuilds.org team members sometimes do that themselves.  
>Sometimes it's quicker than compiling--fair enough--but I consider 
>generally best to make .txz from source code, apart from certain single 
>binaries, which using other GNU/Linux packages is more similar to.  I 
>occasionally run into problems with converted .debs & .rpms, though 
>can't remember the last time that happened from SlackBuilds.org.  I also 
>just like to see the source code and be able to patch it, even if it 
>might take a minute or several or hours longer (apart from a few very 
>big things like GIMP, google-go-lang, KDE, nodejs, pandoc, webkits... 
>used to compile GIMP & KDE on NetBSD UNIX which I then saw 100+ 
>dependencies or took a week).
>         For Thorium, repackaging an arbitrary .deb defeats its entire 
>purpose that it's meant to run compiled native to a large variety of 
>CPUs and be as fast as it can on each including not slower on newer ones.
>         It also seems to be by one of the people who's simply using 
>line #1 of slack-desc (and not filling it out) rather than using 
>projects' READMEs nor writing a helpful one at all.  I ask that a rule 
>be made to include proper README, and fill out slack-desc accordingly.
>         That being said, thorium.SlackBuild is more than two years old 
>by apparently inactive maintainer, so likely will be considered orphaned 
>if not already.  I would not recommend using that version (if security 
>is an issue) rather than official fork the creator's source-code 
>repository links to the guy temporarily helping him, though they've only 
>made beta versions most this year.


There's no silver bullet for writing README
Note that README is used to show some information about the script, so you
don't really need to include the WHOLE documentation or license.
Simple one line is fine since it shows what the script is all about.
If you need more detailed and technical note, that's fine too. Or you can make
separate README.SBo that's also fine.

I usually make README from what upstream provides in their README's project.
That is enough to give information about the script and if users need more
information about the project, they have a link to the project itself and see
the complete docs.

Also, repackaging doesn't mean it's bad. It's just another option of creating
Slackware native package. Anyway, if you feel that it's bad for you, then you
can simply not use it. That simple, no need to bash other people for
contributing to the project. Not everyone has time and passion to track for
dependencies and time to wait for perfect build or even enough hardware to
build everything from source.

As for the outdated script, i agree with that and it should be orphaned as the
maintainer's last activity was 2 years ago. I will leave Urchlay to decide on
orphaning scripts.



--
Willy Sudiarto Raharjo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 870 bytes
Desc: OpenPGP digital signature
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20260926/9e9ac457/attachment.asc>