The reference for the metadata cache points to https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-15900013 which does not exist any more (since it is the live version). The following link to the council-approved version should be used instead: https://projects.gentoo.org/pms/6/pms.html#x1-16500013.2
Created attachment 498350 [details, diff] Patch for GLEP 64
@blueness: Please ack.
(In reply to Ulrich Müller from comment #2) > @blueness: Please ack. Hi Ulrich, it looks good but I don't get this line: "The metadata cache may be incomplete or non-existent, and may contain additional bogus entries." I thought the point was to mandate making that information evailable so that other tools could use it. Can you clarify where that sentence came from?
(In reply to Anthony Basile from comment #3) > Hi Ulrich, it looks good but I don't get this line: "The metadata cache may > be incomplete or non-existent, and may contain additional bogus entries." I > thought the point was to mandate making that information evailable so that > other tools could use it. Can you clarify where that sentence came from? That sentence is there since a long time (namely 2009): https://gitweb.gentoo.org/proj/pms.git/commit/?id=ef961a6f9b91fc0e4ff41da84a3f92888c13d116 I guess the intention of it was that future developments of the cache format should not be blocked (as is the case indeed with Portage's md5-cache). Since GLEP 64 references the section only for the list of variables, I suppose it is no problem? @blueness: BTW, could you please also ack that the GLEP can be distributed under a CC-BY-SA-3.0 license (see bug 631208)?
(In reply to Ulrich Müller from comment #4) > (In reply to Anthony Basile from comment #3) > > Hi Ulrich, it looks good but I don't get this line: "The metadata cache may > > be incomplete or non-existent, and may contain additional bogus entries." I > > thought the point was to mandate making that information evailable so that > > other tools could use it. Can you clarify where that sentence came from? > > That sentence is there since a long time (namely 2009): > https://gitweb.gentoo.org/proj/pms.git/commit/ > ?id=ef961a6f9b91fc0e4ff41da84a3f92888c13d116 > I guess the intention of it was that future developments of the cache format > should not be blocked (as is the case indeed with Portage's md5-cache). > > Since GLEP 64 references the section only for the list of variables, I > suppose it is no problem? > I'm okay with your intentions for that sentence, but I'm worried that other package managers will use it as a loophole and not bother even trying to export their cache. The original concern was with paludis that doesn't export any information about dependent libraries as reported by ldd. This is important to create a map of host's library dependencies for other tools. That sentence is not part of the original GLEP or the intention. I think this should go back to the council for discussion if you want it there. > > @blueness: BTW, could you please also ack that the GLEP can be distributed > under a CC-BY-SA-3.0 license (see bug 631208)? Fine.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/glep.git/commit/?id=f7a67265db3ae26db51e0c3d5bf9daa1ba413c8c commit f7a67265db3ae26db51e0c3d5bf9daa1ba413c8c Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2017-10-10 18:59:14 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2017-10-12 12:12:03 +0000 glep-0064: Fix link to PMS. Link to the latest council-approved PMS version, instead of the live version which is a moving target. Bug: https://bugs.gentoo.org/633964 glep-0064.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)}
(In reply to Anthony Basile from comment #5) > (In reply to Ulrich Müller from comment #4) > > (In reply to Anthony Basile from comment #3) > > > Hi Ulrich, it looks good but I don't get this line: "The metadata cache may > > > be incomplete or non-existent, and may contain additional bogus entries." I > > > thought the point was to mandate making that information evailable so that > > > other tools could use it. Can you clarify where that sentence came from? > > > > That sentence is there since a long time (namely 2009): > > https://gitweb.gentoo.org/proj/pms.git/commit/ > > ?id=ef961a6f9b91fc0e4ff41da84a3f92888c13d116 > > I guess the intention of it was that future developments of the cache format > > should not be blocked (as is the case indeed with Portage's md5-cache). > > > > Since GLEP 64 references the section only for the list of variables, I > > suppose it is no problem? > > > > I'm okay with your intentions for that sentence, but I'm worried that other > package managers will use it as a loophole and not bother even trying to > export their cache. ...which is entirely correct. You *must not* in any circumstances expect the cache to be present and up-to-date. That's the purpose of cache, after all. It's meant to provide means to speed the implementation up when available but it does not replace the original data source. > The original concern was with paludis that doesn't > export any information about dependent libraries as reported by ldd. This > is important to create a map of host's library dependencies for other tools. I don't see how that's relevant to metadata cache at all. The package manager can't know anything about dependent libraries before the package is built, and it certainly can't know them from the ebuild.
(In reply to Michał Górny from comment #7) > (In reply to Anthony Basile from comment #5) > > (In reply to Ulrich Müller from comment #4) > > > (In reply to Anthony Basile from comment #3) > > > > Hi Ulrich, it looks good but I don't get this line: "The metadata cache may > > > > be incomplete or non-existent, and may contain additional bogus entries." I > > > > thought the point was to mandate making that information evailable so that > > > > other tools could use it. Can you clarify where that sentence came from? > > > > > > That sentence is there since a long time (namely 2009): > > > https://gitweb.gentoo.org/proj/pms.git/commit/ > > > ?id=ef961a6f9b91fc0e4ff41da84a3f92888c13d116 > > > I guess the intention of it was that future developments of the cache format > > > should not be blocked (as is the case indeed with Portage's md5-cache). > > > > > > Since GLEP 64 references the section only for the list of variables, I > > > suppose it is no problem? > > > > > > > I'm okay with your intentions for that sentence, but I'm worried that other > > package managers will use it as a loophole and not bother even trying to > > export their cache. > > ...which is entirely correct. You *must not* in any circumstances expect the > cache to be present and up-to-date. That's the purpose of cache, after all. > It's meant to provide means to speed the implementation up when available > but it does not replace the original data source. > > > The original concern was with paludis that doesn't > > export any information about dependent libraries as reported by ldd. This > > is important to create a map of host's library dependencies for other tools. > > I don't see how that's relevant to metadata cache at all. The package > manager can't know anything about dependent libraries before the package is > built, and it certainly can't know them from the ebuild. Consider the tool revdep-rebuild (python version) which imports form gentoolkit which in turn imports portage and uses VARDB to obtain information about linkings between consumers of libraries from NEEDED.ELF.2. This GLEP was supposed to safeguard tools like that. There are other such tools which currently are in use which also operate on assumptions contrary to your above assertions. Also I don't understand your statement "package manager can't know anything about dependent libraries before the package is built" because some information in VARDB is generated *after* the package is emerged.
... and the sentence you are referring to talks of metadata/cache in the repository, and not vardb.
(In reply to Michał Górny from comment #9) > ... and the sentence you are referring to talks of metadata/cache in the > repository, and not vardb. Ah yes. Sorry for the misunderstanding.
