| 1 |
On Sat, 28 Dec 2019 11:14:15 +0000 |
| 2 |
Michael 'veremitz' Everitt <gentoo@×××××××.xyz> wrote: |
| 3 |
|
| 4 |
> I know I'm gonna be shot down in flames, because $heresy, but here is where |
| 5 |
> a package 'database' would actually work quite well, because you can |
| 6 |
> trivially create a query that pulls this data out, and sorts it by package |
| 7 |
> category or maintainer or whatever you like .. |
| 8 |
> |
| 9 |
> Ok, let the flamewars begin ... |
| 10 |
|
| 11 |
There's no real problem with a package database, however, the real |
| 12 |
limitation is in the ebuild source format, which ultimately means any |
| 13 |
such database needs a lot of bash-sourcing hell to simply stay |
| 14 |
up-to-date ( any time an eclass changes, the interpretation of every |
| 15 |
ebuild that uses it also changes, necessitating some pretty fun(1) code ) |
| 16 |
|
| 17 |
And that winds you up fighting with portage internals. |
| 18 |
|
| 19 |
So simply, in order for somebody like me to actually implement such a |
| 20 |
thing, a precursory step is to rewrite enough portage to do just that. |
| 21 |
|
| 22 |
But I haven't (yet) gotten around to that. |
| 23 |
|
| 24 |
|
| 25 |
1: Not actually fun. |
Archives