Salix is missing most repositories about repology-updater HOT 16 OPEN

Upstream (homepage or download) links and links to package recipes (slackbuilds in this case, I think) are required for new submissions. As far as I can see salix does not provide these.

from repology-updater.

I'm not sure I understand what you mean. There are full source code repositories for each one of the package repositories I mentioned, e.g.:
https://download.salixos.org/x86_64/15.0/source/

In any case, if your point was true, why is the 14.2 x86_64 repository already listed in repology? Same question for all Slackware repositories.

from repology-updater.

I'm not sure I understand what you mean.

I need upstream homepage and/or download URLs and URL to slackbuilds for each package.

There are full source code repositories for each one of the package repositories I mentioned, e.g.: https://download.salixos.org/x86_64/15.0/source/

That would work if URLs to SLKBUILDs may be constructed from package fields. It's not true for slackware, but it may be true for salix.

from repology-updater.

What do you mean by "upstream"? Do you mean each package's respective homepage? For example https://www.libreoffice.org/ for libreoffice and a download for the source tarball in libreoffice's servers?

What would the point in that be? As I noted earlier, there are full source code repositories, for example for the libreoffice package that is here:
https://download.salixos.org/x86_64/15.0/salix/xap/libreoffice-7.5.2.1-x86_64-1gv.txz
there are the respective sources here:
https://download.salixos.org/x86_64/15.0/source/xap/libreoffice/
including build scripts and source tarballs.

Similarly for almost every package in the repositories.

For many of the packages, upstream links may not exist anymore (either defunct webpages or projects choose to delete all but the latest tarball). So I'm still not certain what you are looking for here.

And I ask again: if that is a prerequisite for adding repositories in repology, why was the single salix 14.2 repository added and why have the slackware repositories been added?

As it is, repology provides completely misleading information about what is included in the Salix repositories. I think I can be sure that is not your intention.

from repology-updater.

For example https://www.libreoffice.org/ for libreoffice and a download for the source tarball in libreoffice's servers?

Yes.

What would the point in that be?

Upstream URLs are required to distinguish similarly named (yet different) projects. In absence of urls, packages with ambiguous names end up like this, mixed up with other packages with the same lack of information and pessimized by assuming outdatedness.

including build scripts and source tarballs

Repology does not parse scripts and tarballs, however it needs to provide links to these, so the question whether these links can be generated from e.g. source or loc+name fields in PACKAGES.json is still valid.

For many of the packages, upstream links may not exist anymore

Repology is also capable of reporting these.

from repology-updater.

For most (but not all) packages, it would be possible to do that. For example, for the libreoffice scripts linked in the previous post, the SLKBUILD file includes the line:

url=https://www.libreoffice.org/

For the ones in the extra-* repos, you can scan the respective *.info files, e.g. in:
https://download.salixos.org/i486/extra-15.0/source/academic/AlphaPlot/AlphaPlot.info
you can find:

HOMEPAGE="https://alphaplot.sourceforge.io/"

from repology-updater.

For example, for the libreoffice scripts linked in the previous post, the SLKBUILD file includes the line

Merging data from multiple sources (such as PACKAGES.json + SLKBUILDS) would overcomplicate the update process, we're not doing that.

For the ones in the extra-* repos, you can scan the respective *.info files

These are good as long as it's possible to fetch these in one go (that is, not by fetching each file individually) and without upstream sources. For instance, for slackbuilds we parse .info files from git repository. Still, supporting extras alone would not solve the task of adding complete support for salix.

from repology-updater.

What you request is impossible. I suggest that you remove the Salix repositories from repology as they are misleading as they are. Additionally, you should probably also remove Slackware repositories, since they do not adhere to your standards either.

from repology-updater.

Sure that is possible, the questions is whether there's interest in Salix/Slackware communities in providing accurate and usable metadata on their repositories for Repology and other similar tools so these could provide information on outdatedness, vulnerabilities and other stuff in return.

from repology-updater.

I am the lead Salix developer. It is impossible to add the information you request. I can also guarantee you that Pat Volkerding will not change the Slackware repository structure to accomodate any 3rd party metadata parser.

from repology-updater.

I'm not suggesting to change repository structure. You yourself suggested that required information is already available, so it's just the matter of publishing it in some usable form. You already have machinery which generates PACKAGES.json, which could be extended with a few fields. If there's interest.

from repology-updater.

No, it won't, as PACKAGES.json (or the respective PACKAGES.TXT files) is not meant for that purpose. There are things that would potentially break if additional fileds were to be included. If you want the information, it's there for you to parse as I suggested.

from repology-updater.

No, it won't, as PACKAGES.json (or the respective PACKAGES.TXT files) is not meant for that purpose. There are things that would potentially break if additional fileds were to be included.

Sure, that is why you may want to generate different file for the purpose.

If you want the information, it's there for you to parse as I suggested

That is not practical in a lot of ways. It does not make sense to duplicate machinery you already have, and I won't be able to do it properly without knowledge of salix/slackware repository structure. On top of that I won't be able to maintain it as I'm not salix developer and I don't follow its changes, so it will eventually break and we'll end up here again.

from repology-updater.

Perhaps I may take a look at creating such a file as you suggest in the future. In the meantime, the information provided by repology for Salix is incomplete and misleading. I therefore suggest that you remove it.

And if you're not interested in being accused of double standards, you should probably also remove Slackware.

from repology-updater.

Perhaps I may take a look at creating such a file as you suggest in the future

Thank you, I'm looking forward to it!

from repology-updater.

As I requested earlier, in the meantime, please remove Salix from repology. I sometimes get emails from users asking why this or that package is not shown in repology since they are obviously there. Indeed, such an email was the reason I opened this issue here.

from repology-updater.