Closed tim-lebedkov closed 5 months ago
Are there direct links to these files or a way to link to the package page with Contents
opened?
These files are embedded in the repository .xml file so that there is only one link for this, e.g. https://www.npackd.org/rep/xml?tag=stable64 No, there is currently no way to link directly so that "Contents" is opened. Is this really necessary? The files are only one click away.
Yes, since I've missed this, other users can too, and we require transparency in a sense that one should be able to see package sources with one click from repology.
These files are embedded in the repository .xml file
Btw, is that large file an original source, or is it compiled from some more editable form, like a directory tree with per-package xml's and other data? In the latter case, a link to such source is what is required.
And for instance, this package: https://www.npackd.org/p/io.mpv.mpv/0.37. It says version 0.37, but the download is for 0.35, and there's nothing which would prove that the version is not fake. That's exactly what the warning is about, non-transparent or fake data.
I don't agree with you regarding the "accordion" component. In my opinion a user can easily find the files. The data is stored in a database so there are no actual files.
About MPV 0.37: it is just a mistake and should be corrected. How is it not transparent? You were able to easily find the error. I bet any package manager has errors in their repositories.
How about the "Edit as XML" as shown here: https://www.npackd.org/rep/edit-as-xml?package=org.7-zip.SevenZIP64&version=23.1 ?
Is that enough?
About MPV 0.37: it is just a mistake and should be corrected. You were able to easily find the error. I bet any package manager has errors in their repositories.
It's not a single error, there are hundreds (small sample) of packages with this problem.
How about the "Edit as XML" as shown here:
Could do. But versions problem is now fatal.
Do you have the full list?
I have more complete lists, but these are not complete and accurate still, as I'm relying on heuristics.
1.2.3
matches example.com/foo10203.zip
)
https://gist.github.com/AMDmi3/c6309f84e826dd7bacc30098118bd3a5Thank you
I fixed all the problems. Please re-check.
Any news here?
I no longer think that adding link to edit-as-xml
as a recipe link would bring any good as it lists the same content as on a package page, just in a less readable manner. Since the warning looks at the recipe links and there will be no recipe links it won't go away, but I don't feel like adding special case handling for npackd. You should just ignore it.
Many thanks for fixing the data though!
Please reopen the issue. I would like the warning to be removed. What would be an acceptable solution?
I don't see neither acceptable solution nor the need for it. Repology requires package recipes, hence the warning. You don't have package recipes, so there's no way to remove it. This is ok, you should just ignore it. I'm not spending any more time on this.
Projects affected
https://repology.org/repository/npackd_stable https://repology.org/repository/npackd_stable64 https://repology.org/repository/npackd_unstable
Observed behavior
Repology shows this warning:
This repository does not provide links to package recipes or sources in a way accessible by Repology. This is critical, because one of the goals of Repology is to make the details of how a project is packaged visible to anyone. It makes Repology maintenance harder as it's not possible to easily check where a specific version comes from; it does not allow upstream to check the recipe and improve their software to simplify packaging, or suggest corrections to the maintainer; it does not allow other maintainers to learn new ideas. It may be as well dangerous to users due to lack of transparency. Because of that, this repository is subject to removal in the near future.
See documentation for a best way to make package metadata available for Repology.
Expected behavior
No warning. The recipes are open source under GPLv3. Here is an example (under "Text files"): https://www.npackd.org/p/com.videolan.VLCMediaPlayer64/3.0.20
Or do you really mean recipes to create the software packages themselves? This would actually rule out all not source based repositories. And what about closed source software?