Salix is missing most repositories #1346
Comments
|
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. |
|
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.: 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. |
I need upstream homepage and/or download URLs and URL to slackbuilds for each package.
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. |
|
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: 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. |
Yes.
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.
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.
Repology is also capable of reporting these. |
|
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: For the ones in the extra-* repos, you can scan the respective *.info files, e.g. in: |
Merging data from multiple sources (such as PACKAGES.json + SLKBUILDS) would overcomplicate the update process, we're not doing that.
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 |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
Sure, that is why you may want to generate different file for the purpose.
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. |
|
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. |
Thank you, I'm looking forward to it! |
|
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. |
I can see there is already an entry for Salix, but it only includes a single repository for version 14.2 and only for the x86_64 architecture, therefore you are missing 10s of thousands of packages.
Issues:
Similarly for version 15.0 and architecture i486:
For version 14.2, x86_64:
And for version 14.2, i486:
The text was updated successfully, but these errors were encountered: