PLD Linux: linux-live version abuse

[blshkv]

https://repology.org/metapackage/linux-live/versions
https://git.pld-linux.org/?p=packages/linux-live.git;a=blob;f=linux-live.spec;h=3c9001fc6c0192772a496b922d2346655c59ded3;hb=ddc86486bb2803ff399438e772e7518fcac72cf0

The latest release is 2.1
https://github.com/Tomas-M/linux-live/releases

[AMDmi3]

Hmm, I wonder why's it 6.3.0 while .spec says Version: 1.8

[AMDmi3]

@glensc 👋 sorry for disturbing, but maybe you could shed some light on this

[glensc]

what is this?!

anyway please see full history of the git repository, it used slax linux-live previously:

• http://git.pld-linux.org/?p=packages/linux-live.git;a=summary

and the epoch bump when version was decreased, so all is correct in distro sense.

and it's the project author who reset versioning, you're probably seeing built rpm package from the previous generation from ftp.pld-linux.org

[AMDmi3]

what is this?!

repology is the service which compares package versions in a lot of repositories, tracks package updates and reports outdated packages (for which newer version is known).

and the epoch bump when version was decreased, so all is correct in distro sense
you're probably seeing built rpm package from the previous generation from ftp.pld-linux.org

That's it, thanks for the insight! Seems like the outdated RPM is the problem. Unfortunately I haven't found any alternative source for PLD packages versions. Maybe you have any ideas?

[glensc]

built .rpm files on ftp != git repository for .spec

what is your definition of repository?

• rpm repository (built rpm's on ftp)
• git repository (git repo with source for .spec and .patch)

[AMDmi3]

Any source of package names+versions and, if possible, other information (homepage and download urls, maintainer, summary, categories etc.). Sources are obviously preferred as they are genuine, but it's hard to handle thousands of separate per-package repositories (which IIRC is the case for PLD Linux) and it's currently not possible to parse .specs. Some repos provide some kind of index which is easier to parse (a web site or API, or repository index used by package utilities, or, the best of all, a machine parsable dump), but I couldn't find any for PLD linux, only a list of RPMs. I ask because maybe there is something not widely announced, or someone of PLD devs would be interested in creating one. There seem to be demand, as someone asked to add PLD support to repology (repology/repology-updater#604).

[glensc]

package sources are not genuine. built packages on ftp are genuine. as in this specific case, source spec has been updated, but the new version is not built as it's not complete.

pld ftp has indexes for repodata (repomd) and poldek format (packages.*)

• http://ftp.pld-linux.org/dists/th/PLD/noarch/RPMS/repodata/
• http://ftp.pld-linux.org/dists/th/PLD/x86_64/RPMS/repodata/

if you want to parse .spec files from ftp, you may want to look at the SRPMS directory.

• http://ftp.pld-linux.org/dists/th/PLD/SRPMS/RPMS/

oh. there's machine parsable .metadata folder, but it's not accessible over http nor ftp somewhy

• http://ftp1.pld-linux.org/dists/th/PLD/SRPMS/.metadata/
• ftp://ftp1.pld-linux.org/dists/th/PLD/SRPMS/.metadata/

[blshkv]

so the long story short: the version 6.3.0 (http://ftp.pld-linux.org/dists/th/PLD/SRPMS/RPMS/linux-live-6.3.0-1.src.rpm) is 9 years old and no longer available for download from the official website.
Some distros have not upgraded it since then.

Later, upstream has changed version scheme and the latest version 2.1

[AMDmi3]

package sources are not genuine. built packages on ftp are genuine.

I can't agree with that, as by definition specs are genuine as RPMs are produced from them. It's true however that users do see RPMs, not .specs, but Repology is currently more maintainer-focused, and the source state is more useful both for maintainers and as a source of fresh versions. Maybe at some point in future we'll support both source and binary packages with a mapping between them.

pld ftp has indexes for repodata (repomd)

That would be useful for SRPMS, but not for binary packages, as these contain splits (foo, foo-devel, foo-docs etc.) which are generally impossible to merge back into projects which can be compared to other distros.

oh. there's machine parsable .metadata folder, but it's not accessible over http nor ftp somewhy

That would be interesting to look at...

[AMDmi3]

so the long story short: the version 6.3.0 (http://ftp.pld-linux.org/dists/th/PLD/SRPMS/RPMS/linux-live-6.3.0-1.src.rpm) is 9 years old

Well I'll just add a rule so it's considered outdated when compared to newer scheme versions.

[glensc]

i just recalled, there is single repo where all packages .spec files are committed:

• https://www.pld-linux.org/repositories#git_repositories

SPECS - copy of all packages .spec files from HEAD, clone url: git://git.pld-linux.org/SPECS

[glensc]

aside, removed outdated linux-live from th repository. it may take few days for mirrors to update

pldth@ep09-pld SRPMS/.metadata$ pfa-mvpkg PLD .archive/PLD linux-live-6.3.0-1.src.rpm.info

[glensc]

also made .metadata accessible:

• http://ftp1.pld-linux.org/dists/th/PLD/SRPMS/.metadata/

the directory lacked world accessible permissions:

pldth@ep09-pld SRPMS/.metadata$ chmod -R a+rX .

[APIPLM]

Maybe at some point in future we'll support both source and binary packages with a mapping between them.

It is not necessary to the mapping between source and binary packages. I mean that it might be too complex for some case . Let us say @glensc mentioned that case in the above.

in this specific case, source spec has been updated, but the new version is not built as it's not complete.

that source spec is more like having a release plan for a package. Mapping between source and binary packages, it is more like maintenance repo for different release, obviously that is not you are supposed to do, git is there. So most like as maintainers need to know that release(binary packages) plan for spec and the spec, and then the builder environment of each release(binary packages) and planned version of the source in git repo . Because the release always there after running thorough the process. all test cases success, then get approved, or issue solved process.