Re: [gentoo-dev] RFC: GLEP 64: Export Package Manager Cached Information. (Was: RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information.)
On 09/07/14 22:36, Patrick Lauer wrote: On Saturday 06 September 2014 16:22:46 hasufell wrote: Anthony G. Basile: On 09/06/14 12:12, hasufell wrote: Anthony G. Basile: And when you do ask, is a package that's provided installed, and if so, what's its metadata? When the package is installed, that data should have been cached. Afaik there is nothing cached if you put stuff in package.provided. It's a terrible hack, unless I missed something. I wasn't sure what Ciaran was talking about there. If its hacky, then we certainly don't want to standardize it in the GLEP. Well, you have to to define what tools can expect from provided/installed packages. That means either say you cannot expect anything, because there might or might not be metadata or say you can expect metadata for any provided/installed package in which case package.provided feature has to be removed from portage. Provided means not managed by the package manager and thus returning empty metadata for queries is perfectly fine. I don't see why this feature would need to be removed ... I will explicitly mention package.provided in the GLEP as not returning anything for metadata. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] RFC: GLEP 64: Export Package Manager Cached Information. (Was: RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information.)
Patrick Lauer: On Saturday 06 September 2014 16:22:46 hasufell wrote: Anthony G. Basile: On 09/06/14 12:12, hasufell wrote: Anthony G. Basile: And when you do ask, is a package that's provided installed, and if so, what's its metadata? When the package is installed, that data should have been cached. Afaik there is nothing cached if you put stuff in package.provided. It's a terrible hack, unless I missed something. I wasn't sure what Ciaran was talking about there. If its hacky, then we certainly don't want to standardize it in the GLEP. Well, you have to to define what tools can expect from provided/installed packages. That means either say you cannot expect anything, because there might or might not be metadata or say you can expect metadata for any provided/installed package in which case package.provided feature has to be removed from portage. Provided means not managed by the package manager and thus returning empty metadata for queries is perfectly fine. I don't see why this feature would need to be removed ... You just rephrased you cannot expect anything, because there might or might not be metadata.
Re: [gentoo-dev] RFC: GLEP 64: Export Package Manager Cached Information. (Was: RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information.)
Anthony G. Basile: On 09/07/14 22:36, Patrick Lauer wrote: On Saturday 06 September 2014 16:22:46 hasufell wrote: Anthony G. Basile: On 09/06/14 12:12, hasufell wrote: Anthony G. Basile: And when you do ask, is a package that's provided installed, and if so, what's its metadata? When the package is installed, that data should have been cached. Afaik there is nothing cached if you put stuff in package.provided. It's a terrible hack, unless I missed something. I wasn't sure what Ciaran was talking about there. If its hacky, then we certainly don't want to standardize it in the GLEP. Well, you have to to define what tools can expect from provided/installed packages. That means either say you cannot expect anything, because there might or might not be metadata or say you can expect metadata for any provided/installed package in which case package.provided feature has to be removed from portage. Provided means not managed by the package manager and thus returning empty metadata for queries is perfectly fine. I don't see why this feature would need to be removed ... I will explicitly mention package.provided in the GLEP as not returning anything for metadata. Please don't. This is portage internal stuff and shouldn't be in the spec. The important part is whether API users can always expect non-empty valid metadata or not. Is there any good argument for allowing empty metadata except to support a broken portage implementation?
Re: [gentoo-dev] RFC: GLEP 64: Export Package Manager Cached Information. (Was: RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information.)
That means either say you cannot expect anything, because there might or might not be metadata or say you can expect metadata for any provided/installed package in which case package.provided feature has to be removed from portage. Provided means not managed by the package manager and thus returning empty metadata for queries is perfectly fine. I don't see why this feature would need to be removed ... You just rephrased you cannot expect anything, because there might or might not be metadata. So you're saying that if I remove metadata it is removed. Our tautology circle is true! Thanks for contributing these awesome insights.
Re: [gentoo-dev] RFC: GLEP 64: Export Package Manager Cached Information. (Was: RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information.)
Patrick Lauer: That means either say you cannot expect anything, because there might or might not be metadata or say you can expect metadata for any provided/installed package in which case package.provided feature has to be removed from portage. Provided means not managed by the package manager and thus returning empty metadata for queries is perfectly fine. I don't see why this feature would need to be removed ... You just rephrased you cannot expect anything, because there might or might not be metadata. So you're saying that if I remove metadata it is removed. Our tautology circle is true! Thanks for contributing these awesome insights. I'm saying that you didn't make an actual argument why it is better to allow non-existing metadata for installed packages and have every API user handle this exception. This will go horribly wrong if we start designing an API around portage hacks, assuming that the VDB might just be broken, inconsistent or maybe valid. Is this about a portage API or a generic PM API? If it's about the former, then I'd rather see eix and friends broken for other PMs instead of spreading portage hacks over them (FYI: paludis has the provided case implemented without breaking VDB).
Re: [gentoo-dev] RFC: GLEP 64: Export Package Manager Cached Information. (Was: RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information.)
On Saturday 06 September 2014 16:22:46 hasufell wrote: Anthony G. Basile: On 09/06/14 12:12, hasufell wrote: Anthony G. Basile: And when you do ask, is a package that's provided installed, and if so, what's its metadata? When the package is installed, that data should have been cached. Afaik there is nothing cached if you put stuff in package.provided. It's a terrible hack, unless I missed something. I wasn't sure what Ciaran was talking about there. If its hacky, then we certainly don't want to standardize it in the GLEP. Well, you have to to define what tools can expect from provided/installed packages. That means either say you cannot expect anything, because there might or might not be metadata or say you can expect metadata for any provided/installed package in which case package.provided feature has to be removed from portage. Provided means not managed by the package manager and thus returning empty metadata for queries is perfectly fine. I don't see why this feature would need to be removed ...
[gentoo-dev] RFC: GLEP 64: Export Package Manager Cached Information. (Was: RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information.)
Hi everyone, I've incorporated suggestions from the previous round of discussions in the GLEP. In particular, note that I also changed the title to avoid referring to VDB as the means for caching. Each package manager can decide how to cache the information internally. The working copy is at https://wiki.gentoo.org/wiki/User:Blueness/GLEP64 The essential point I'm trying to make is: 1) there is information generated when a PM builds+installs a package. 2) some of this information is expensive to regenerate. 3) there are utilites that would like to make use of this information. 4) to spare these utilites the expense of regenerating this information, all package managers should cache this information and then export it via a common API. Thanks in advance for your time! -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] RFC: GLEP 64: Export Package Manager Cached Information. (Was: RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information.)
On Sat, 06 Sep 2014 09:03:13 -0400 Anthony G. Basile bluen...@gentoo.org wrote: Note that, as with the Metadata Cache, these variable should be stored with all the conditionals evaluated. Paludis doesn't do this (and historically, Portage didn't either). We store USE etc. This is useful because it allows us to detect when people have been mucking around with DEPEND and the like. A list of all files belonging to the package, along with a designation of the file type (regular, directory, symlink, pipe, etc), MD5SUM or other checksum, and mtime time. Packages aren't allowed to install pipes. A list of all executable or shared objects for each package and the corresponding linking information, including full path to the object, its architecture and ABI, SONAME, RPATH and any NEEDED objects they link against, as reported by `readelf` on ELF systems, or similar tools for other executable formats. Currently this information is being cached by Portage in NEEDED.ELF.2, NEEDED.MACHO.3, NEEDED.XCOFF, NEEDED.PECOFF, etc. This is utterly arbitrary, and introduces a dependency on particular non-standard package whose behaviour we don't control. Not everything is C and ELF, and we shouldn't be encouraging solutions that make the assumption that they are... You've also not discussed how this interacts with Portage's package.provided misfeature. Finally, you don't have any way of using this information, since you don't have a way of knowing what packages are installed. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: GLEP 64: Export Package Manager Cached Information. (Was: RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information.)
Anthony G. Basile: A list of all files belonging to the package, along with a designation of the file type (regular, directory, symlink, pipe, etc), MD5SUM or other checksum, and mtime time. Packages aren't allowed to install pipes. Okay I will remove pipes. Do you have a reference btw about what types of files can be installed. http://dev.gentoo.org/~ulm/pms/head/pms.html#x1-15800012.6 12.6 Other Files Ebuilds must not attempt to install any other type of file (FIFOs, device nodes etc). The explicit list of allowed ones is in the chapters above.
Re: [gentoo-dev] RFC: GLEP 64: Export Package Manager Cached Information. (Was: RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information.)
On Sat, 06 Sep 2014 09:51:58 -0400 Anthony G. Basile bluen...@gentoo.org wrote: Paludis doesn't do this (and historically, Portage didn't either). We store USE etc. This is useful because it allows us to detect when people have been mucking around with DEPEND and the like. This was a suggestion from mgorny and I trust his opinion on the matter. It does make sense to have metadata catche which is conditionally evaluated be exported. Well what are you planning to use it for? Are you really suggesting that people are going to implement EAPI-aware, compliant dependency parsers that can't figure out conditionals? 1) This cannot be utterly arbitrary because there are utilities and portions of portages code which does make use of precisely this information. What Portage does internally is up to Portage. What we don't want is to encourage external utilities that are utterly inflexible and that make strange assumptions. 2) With the exception of some embedded systems where everything is statically linked, all modern systems have dynamic linking. And all dynamic linking has information in its objects which associates the executables with the library they link against. This is the essential information to be stored. Which isn't what you're asking for... You're asking for it in a particular format. 6) Without a standard here, we have utilites which make use of this cached information in the tree which only work with portage but not paludis. This problem can be solved by removing those utilities, which is undesireable, by standardizing what needs to be exported from the PM, or by living with the status quo which is having useful packages in the tree which don't work with paludis. The solution is to replace those utilities with something that works in proper generality. You've also not discussed how this interacts with Portage's package.provided misfeature. Finally, you don't have any way of using this information, since you don't have a way of knowing what packages are installed. I don't understand your reasoning behind these points, can you please explain. Well you can't ask for information about packages unless you know what's installed, and you haven't asked for a general API for that. And when you do ask, is a package that's provided installed, and if so, what's its metadata? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: GLEP 64: Export Package Manager Cached Information. (Was: RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information.)
On 09/06/14 10:04, Ciaran McCreesh wrote: On Sat, 06 Sep 2014 09:51:58 -0400 Anthony G. Basile bluen...@gentoo.org wrote: Paludis doesn't do this (and historically, Portage didn't either). We store USE etc. This is useful because it allows us to detect when people have been mucking around with DEPEND and the like. This was a suggestion from mgorny and I trust his opinion on the matter. It does make sense to have metadata catche which is conditionally evaluated be exported. Well what are you planning to use it for? Are you really suggesting that people are going to implement EAPI-aware, compliant dependency parsers that can't figure out conditionals? No, but the resolution of the conditionals may change over time and it would be nice to have the information as it was at the time of the build. However, this point is minor. I'm certain something can be worked out among the PMS people as to what is best here. After all, the request did come from the portage camp. 1) This cannot be utterly arbitrary because there are utilities and portions of portages code which does make use of precisely this information. What Portage does internally is up to Portage. What we don't want is to encourage external utilities that are utterly inflexible and that make strange assumptions. Neither do we want to hamper what developers might want to do. The authors of sys-apps/elfix, app-portage/gentoolkit, app-portage/portage-utils, app-portage/eix are not utterly inflexible utilities makeing strange assumptions. They are useful utilities as anyone following this thread would agree. Their assumption would go from being non-standard to standard with the acceptance of this GLEP. They would then operate with both portage and paludis. 2) With the exception of some embedded systems where everything is statically linked, all modern systems have dynamic linking. And all dynamic linking has information in its objects which associates the executables with the library they link against. This is the essential information to be stored. Which isn't what you're asking for... You're asking for it in a particular format. I will incorporate better language which goes to the heart of what's needed and makes the ELF quantities an example rather than the demanded format. In other words, I will remove the ELF bias. Since dynamic linking information is generated at build time, is expensive to regenerate and is useful to other utilities, it falls under the scope of the GLEP. Of course we wish to extend this to any executable format. We focus on ELF because of its familiarity, but not at the exclusion of others. 6) Without a standard here, we have utilites which make use of this cached information in the tree which only work with portage but not paludis. This problem can be solved by removing those utilities, which is undesireable, by standardizing what needs to be exported from the PM, or by living with the status quo which is having useful packages in the tree which don't work with paludis. The solution is to replace those utilities with something that works in proper generality. You can do this, but it would be terribly inefficient to regenerate expensive information already generated by PM. For example, `equery` from gentoolkit allows the user to gather all sorts of information about installed packages, eg. What package does this file belongs to? A very natural question. Without this information cached in portage's VDB, how would equery do this? It would have to rebuild package by package until it finds one that gives the file we're looking for?! This is absurd. Rather gentoolkit opens up /var/db/pkg and read the information out of there. For gentoolkit to work in proper generality we would need PM's to export this information by some common API, so there is a generality. That's what GLEP 64 is about. You point argues in favor of the GLEP. You've also not discussed how this interacts with Portage's package.provided misfeature. Finally, you don't have any way of using this information, since you don't have a way of knowing what packages are installed. I don't understand your reasoning behind these points, can you please explain. Well you can't ask for information about packages unless you know what's installed, and you haven't asked for a general API for that. Ah, okay. That should be added explicitly since its only implied right now. Thanks. And when you do ask, is a package that's provided installed, and if so, what's its metadata? When the package is installed, that data should have been cached. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] RFC: GLEP 64: Export Package Manager Cached Information. (Was: RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information.)
Anthony G. Basile: And when you do ask, is a package that's provided installed, and if so, what's its metadata? When the package is installed, that data should have been cached. Afaik there is nothing cached if you put stuff in package.provided. It's a terrible hack, unless I missed something.
Re: [gentoo-dev] RFC: GLEP 64: Export Package Manager Cached Information. (Was: RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information.)
On 09/06/14 12:12, hasufell wrote: Anthony G. Basile: And when you do ask, is a package that's provided installed, and if so, what's its metadata? When the package is installed, that data should have been cached. Afaik there is nothing cached if you put stuff in package.provided. It's a terrible hack, unless I missed something. I wasn't sure what Ciaran was talking about there. If its hacky, then we certainly don't want to standardize it in the GLEP. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] RFC: GLEP 64: Export Package Manager Cached Information. (Was: RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information.)
On Sat, 06 Sep 2014 12:07:10 -0400 Anthony G. Basile bluen...@gentoo.org wrote: No, but the resolution of the conditionals may change over time and it would be nice to have the information as it was at the time of the build. You have USE available... Neither do we want to hamper what developers might want to do. The authors of sys-apps/elfix, app-portage/gentoolkit, app-portage/portage-utils, app-portage/eix are not utterly inflexible utilities makeing strange assumptions. They are useful utilities as anyone following this thread would agree. Their assumption would go from being non-standard to standard with the acceptance of this GLEP. They would then operate with both portage and paludis. Well eix is buggy, PMS-violating and doesn't support EAPIs properly, and the utilities in gentoolkit and portage-utils are better implemented natively in a package manager. I don't know what elfix does, but if it's anything like the other three, I'd rather reimplement it in a PMS compliant manner for Paludis than to provide flaky external APIs that encourage people to write broken code... You can do this, but it would be terribly inefficient to regenerate expensive information already generated by PM. For example, `equery` from gentoolkit allows the user to gather all sorts of information about installed packages, eg. What package does this file belongs to? A very natural question. Without this information cached in portage's VDB, how would equery do this? It would have to rebuild package by package until it finds one that gives the file we're looking for?! This is absurd. Rather gentoolkit opens up /var/db/pkg and read the information out of there. It would use a package-manager provided interface to do it, which would remove the need to implement direct VDB reading externally. This is good, because reading VDB *correctly* is difficult, and we don't want lots of third party tools doing it badly. For example, with Paludis, you would do 'cave print-owners' to get this information, and your code works correctly even if VDB switches formats and even if it isn't located at /var/db/pkg. For gentoolkit to work in proper generality we would need PM's to export this information by some common API, so there is a generality. That's what GLEP 64 is about. You point argues in favor of the GLEP. Well gentoolkit is Portage-specific, since we've reimplemented all the useful stuff properly in Paludis... To reimplement gentoolkit in proper generality, externally, you'd need an awful lot more than what you're asking for. And when you do ask, is a package that's provided installed, and if so, what's its metadata? When the package is installed, that data should have been cached. But package.provided packages *aren't* installed. They are merely treated as if they were installed, without actually being installed, so that data isn't available. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: GLEP 64: Export Package Manager Cached Information. (Was: RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information.)
Anthony G. Basile: On 09/06/14 12:12, hasufell wrote: Anthony G. Basile: And when you do ask, is a package that's provided installed, and if so, what's its metadata? When the package is installed, that data should have been cached. Afaik there is nothing cached if you put stuff in package.provided. It's a terrible hack, unless I missed something. I wasn't sure what Ciaran was talking about there. If its hacky, then we certainly don't want to standardize it in the GLEP. Well, you have to to define what tools can expect from provided/installed packages. That means either say you cannot expect anything, because there might or might not be metadata or say you can expect metadata for any provided/installed package in which case package.provided feature has to be removed from portage.
Re: [gentoo-dev] RFC: GLEP 64: Export Package Manager Cached Information. (Was: RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information.)
On 09/06/14 12:18, Ciaran McCreesh wrote: Well eix is buggy, PMS-violating and doesn't support EAPIs properly, and the utilities in gentoolkit and portage-utils are better implemented natively in a package manager. I don't know what elfix does, but if it's anything like the other three, I'd rather reimplement it in a PMS compliant manner for Paludis than to provide flaky external APIs that encourage people to write broken code... elfix contains revdep-pax which does what revdep-rebuild does, except that it migrates PaX flags from executables to libraries and vice versa. There exists a category of tools that can make use of PM's cached information which should not be part of PM. elfix is one such example. Let me give you another: https://bugs.gentoo.org/show_bug.cgi?id=506276#c42. That bug is about removing SYMLINK_LIB=yes. To do so properly and migrate systems that use symlinks for /libXX, vapier wrote a migration script which at one point walk[s] the vdb looking for files that installed into /lib32 and /lib. These sorts of utilites pop up over and over again. You cannot put every utility that needs package information into a package manager. An API for interoperability between PM's and other tools is meaningful. Refusing to do so leads to the sort of comment you see in https://bugs.gentoo.org/show_bug.cgi?id=506276#c43. Ironically, the very standards I seek in GLEP 64 would benefit the paludis world most. When the package is installed, that data should have been cached. But package.provided packages *aren't* installed. They are merely treated as if they were installed, without actually being installed, so that data isn't available. Right. hasufell's email made it clear. This is pretty hacky so we don't want to go there. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] RFC: GLEP 64: Export Package Manager Cached Information. (Was: RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information.)
On Sat, 06 Sep 2014 13:00:03 -0400 Anthony G. Basile bluen...@gentoo.org wrote: On 09/06/14 12:18, Ciaran McCreesh wrote: Well eix is buggy, PMS-violating and doesn't support EAPIs properly, and the utilities in gentoolkit and portage-utils are better implemented natively in a package manager. I don't know what elfix does, but if it's anything like the other three, I'd rather reimplement it in a PMS compliant manner for Paludis than to provide flaky external APIs that encourage people to write broken code... elfix contains revdep-pax which does what revdep-rebuild does, except that it migrates PaX flags from executables to libraries and vice versa. There's a reason we reimplemented revdep-rebuild: doing it *properly* requires passing special information to the dependency resolver telling it not to reuse certain packages for breaking circular dependencies. These sorts of utilites pop up over and over again. A lot of them are because Portage doesn't provide a decent API for users... You cannot put every utility that needs package information into a package manager. No, just the ones that do anything fiddly, and that certainly includes eix and most of gentoolkit. An API for interoperability between PM's and other tools is meaningful. Refusing to do so leads to the sort of comment you see in https://bugs.gentoo.org/show_bug.cgi?id=506276#c43. Ironically, the very standards I seek in GLEP 64 would benefit the paludis world most. I'm not disagreeing with an API for interoperability, in principle. I just think the way you're going about it is all wrong, and we're all better not having an API at all than having a bad one that we'll have to support for all eternity. Here's a quick lesson, starting with bad design: for x in /var/db/pkg/*/* ; do cat $x/DESCRIPTION # etc But what if VDB isn't there? for x in $(pmtool get_vdb_path)/*/* ; do cat $x/DESCRIPTION But */* makes some strong assumptions about the filesystem layout. In particular, it's going to be wrong if we ever do multi-slot. So: for x in $(pmtool get_vdb_package_directories) ; do cat $x/DESCRIPTION But this is still very fragile. What if we switch to sqlite? for x in $(pmtool get_unique_ids_for_vdb_packages) ; do pmtool get_metadata_variable $x DESCRIPTION But hang on... We don't really want VDB. We want installed packages. (This is important, and it's not just a naming thing.) for x in $(pmtool get_unique_ids_for_installed_packages) ; do pmtool get_metadata_variable $x DESCRIPTION What if descriptions move to metadata.xml? for x in $(pmtool get_unique_ids_for_installed_packages) ; do pmtool get_description $x And finally, what if EAPI 7 changes things? It's probably best to error out. export PMTOOL_BARF_ON_UNKNOWN_EAPIS=1 2 3 4 5 6 for x in $(pmtool get_unique_ids_for_installed_packages) ; do pmtool get_description $x Now this is still fragile and makes all kinds of assumptions, and we could argue eternally about the naming, but it's a heck of a lot better than what we started off with. In particular, it's *very* high level, and relies upon the package mangler for everything involving parsing. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: GLEP 64: Export Package Manager Cached Information. (Was: RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information.)
On 09/06/14 13:09, Ciaran McCreesh wrote: I'm not disagreeing with an API for interoperability, in principle. I just think the way you're going about it is all wrong, and we're all better not having an API at all than having a bad one that we'll have to support for all eternity. You and the portage team can get together to discuss how you wish to design this API. The GLEP is clear on this point: It is not the purpose of this GLEP to specify the details of a common API for exporting the above information. Even less so is it our purpose to delineate the implemenatation details for each PM. However, a common API for exporting the above information should be developed and specified by the PM teams and include in future PMS documentation. It is incorrect to say I'm going about it all wrong when I'm not doing any designing. The GLEP specifies the information to be exported, without implementaton details --- it does give mgorny's suggested API only as a suggestion. I've removed all references to VDB as the caching mechanism. Each PM can choose whatever mechanism it wants as long as it caches and exports the information specified in the GLEP. Once the teams decide, they document their common API in PMS. Here's a quick lesson, starting with bad design: Now this is still fragile and makes all kinds of assumptions, and we could argue eternally about the naming, but it's a heck of a lot better than what we started off with. In particular, it's *very* high level, and relies upon the package mangler for everything involving parsing. I trust you and the portage team to do this right. I've simply pointed out instances of utilities which do not belong in a PM, and which can make use of information generated by a PM at build time, but which is expensive to recalculate later. This argues for caching this information and exporting it via a common API so tools can work as well with paludis as with portage as with xyz from the future. At this point I've gotten enough feedback for the next re-write. Basically I'm going to change the emphasis on ELF and make it clearer that we're looking for whatever dynamic linking information is appropriate for the executable format in question and relegate ELF to an example. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] RFC: GLEP 64: Export Package Manager Cached Information. (Was: RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information.)
On Sat, 06 Sep 2014 14:10:50 -0400 Anthony G. Basile bluen...@gentoo.org wrote: It is incorrect to say I'm going about it all wrong when I'm not doing any designing. Not doing any designing *is* going about it all wrong... Getting this right is hard work. Someone needs to do it. At this point I've gotten enough feedback for the next re-write. Basically I'm going to change the emphasis on ELF and make it clearer that we're looking for whatever dynamic linking information is appropriate for the executable format in question and relegate ELF to an example. That's all very well, but it's completely useless until someone designs the whole thing. We're back to specifying the colours of the shelves before we've designed the bikeshed. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: GLEP 64: Export Package Manager Cached Information. (Was: RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information.)
On 09/06/14 14:15, Ciaran McCreesh wrote: On Sat, 06 Sep 2014 14:10:50 -0400 Anthony G. Basile bluen...@gentoo.org wrote: It is incorrect to say I'm going about it all wrong when I'm not doing any designing. Not doing any designing *is* going about it all wrong... Getting this right is hard work. Someone needs to do it. I plan to help the portage team with this. In fact, I really like mgorny's query-installed|| thingy. I am in the process of familiarizing myself with paludis and can help there too. Brace yourself for patches! At this point I've gotten enough feedback for the next re-write. Basically I'm going to change the emphasis on ELF and make it clearer that we're looking for whatever dynamic linking information is appropriate for the executable format in question and relegate ELF to an example. That's all very well, but it's completely useless until someone designs the whole thing. We're back to specifying the colours of the shelves before we've designed the bikeshed. This is the beginings of design. We can talk about something which does not exist and then make it exist. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
