| 1 |
On Sat, 06 Sep 2014 12:07:10 -0400 |
| 2 |
"Anthony G. Basile" <blueness@g.o> wrote: |
| 3 |
> No, but the resolution of the conditionals may change over time and |
| 4 |
> it would be nice to have the information as it was at the time of the |
| 5 |
> build. |
| 6 |
|
| 7 |
You have USE available... |
| 8 |
|
| 9 |
> Neither do we want to hamper what developers might want to do. The |
| 10 |
> authors of sys-apps/elfix, app-portage/gentoolkit, |
| 11 |
> app-portage/portage-utils, app-portage/eix are not "utterly |
| 12 |
> inflexible" utilities makeing "strange assumptions". They are useful |
| 13 |
> utilities as anyone following this thread would agree. Their |
| 14 |
> assumption would go from being non-standard to standard with the |
| 15 |
> acceptance of this GLEP. They would then operate with both portage |
| 16 |
> and paludis. |
| 17 |
|
| 18 |
Well eix is buggy, PMS-violating and doesn't support EAPIs properly, |
| 19 |
and the utilities in gentoolkit and portage-utils are better implemented |
| 20 |
natively in a package manager. I don't know what elfix does, but if |
| 21 |
it's anything like the other three, I'd rather reimplement it in a PMS |
| 22 |
compliant manner for Paludis than to provide flaky external APIs that |
| 23 |
encourage people to write broken code... |
| 24 |
|
| 25 |
> You can do this, but it would be terribly inefficient to regenerate |
| 26 |
> expensive information already generated by PM. For example, `equery` |
| 27 |
> from gentoolkit allows the user to gather all sorts of information |
| 28 |
> about installed packages, eg. "What package does this file belongs |
| 29 |
> to?" A very natural question. Without this information cached in |
| 30 |
> portage's VDB, how would equery do this? It would have to rebuild |
| 31 |
> package by package until it finds one that gives the file we're |
| 32 |
> looking for?! This is absurd. Rather gentoolkit opens |
| 33 |
> up /var/db/pkg and read the information out of there. |
| 34 |
|
| 35 |
It would use a package-manager provided interface to do it, which would |
| 36 |
remove the need to implement direct VDB reading externally. This is |
| 37 |
good, because reading VDB *correctly* is difficult, and we don't want |
| 38 |
lots of third party tools doing it badly. For example, with Paludis, |
| 39 |
you would do 'cave print-owners' to get this information, and your code |
| 40 |
works correctly even if VDB switches formats and even if it isn't |
| 41 |
located at /var/db/pkg. |
| 42 |
|
| 43 |
> For gentoolkit to work "in proper generality" we would need PM's to |
| 44 |
> export this information by some common API, so there is a |
| 45 |
> generality. That's what GLEP 64 is about. You point argues in favor |
| 46 |
> of the GLEP. |
| 47 |
|
| 48 |
Well gentoolkit is Portage-specific, since we've reimplemented all the |
| 49 |
useful stuff properly in Paludis... To reimplement gentoolkit in proper |
| 50 |
generality, externally, you'd need an awful lot more than what you're |
| 51 |
asking for. |
| 52 |
|
| 53 |
> > And when you do ask, is a package that's "provided" installed, and |
| 54 |
> > if so, what's its metadata? |
| 55 |
> |
| 56 |
> When the package is installed, that data should have been cached. |
| 57 |
|
| 58 |
But package.provided packages *aren't* installed. They are merely |
| 59 |
treated as if they were installed, without actually being installed, so |
| 60 |
that data isn't available. |
| 61 |
|
| 62 |
-- |
| 63 |
Ciaran McCreesh |
Archives