Hmm although that then doesn't allow us to have entries like title and description for say openjdk-8 being different than openjdk-6 (if they both point back to a single openjdk entry...)
In that case, perhaps I'll change the code which adds each alias itself as keys to package-db to instead merge the entries if it already exists (and then to keep any non-empty values already in the package-db entry), ie. if we have
Hmm although that then doesn't allow us to have entries like title and description for say openjdk-8 being different than openjdk-6 (if they both point back to a single openjdk entry...)
In that case, perhaps I'll change the code which adds each alias itself as keys to package-db to instead merge the entries if it already exists (and then to keep any non-empty values already in the package-db entry), ie. if we have
"openjdk-6": {
"aliases": [],
"description": "Open Source Java implementation",
"notes": [],
"pkgs": {},
"tags": [],
"title": "OpenJDK 6"
},
and
"openjdk": { openjdk- lts",
"aliases": [
"openjdk-11",
"openjdk-15",
"openjdk-14",
"openjdk-18",
"openjdk-16",
"openjdk-17",
"openjdk-9",
"openjdk-12",
"openjdk-8",
"
"openjdk-13"
],
"notes": [["foo"], ["bar"]],
"pkgs": {...},
...
}
then the final entry for openjdk-6 would end up looking like:
"openjdk-6": { openjdk- lts",
"aliases": [
"openjdk-11",
"openjdk-15",
"openjdk-14",
"openjdk-18",
"openjdk-16",
"openjdk-17",
"openjdk-9",
"openjdk-12",
"openjdk-8",
"
"openjdk-13"
],
"description": "Open Source Java implementation",
"notes": [["foo"], ["bar"]],
"pkgs": {...},
"tags": [],
"title": "OpenJDK 6"
},