| 1 |
Hi, |
| 2 |
|
| 3 |
On Tue, 2004-11-02 at 16:00, Daniel Drake wrote: |
| 4 |
> On Monday 01 November 2004 15:52, Henrik Brix Andersen wrote: |
| 5 |
> > Hmmm... tough question. Currently 729 ebuilds in the portage tree uses |
| 6 |
> > ${KV} and only 57 use ${KV_PATCH}. It seems that many ebuilds rely on |
| 7 |
> > knowing the kernel version but not many rely on knowing the kernel |
| 8 |
> > version in details. |
| 9 |
> |
| 10 |
> That isn't exactly the point here - portage does parse out all of those things |
| 11 |
> in order to construct $KV anyway, so could very easily be extended to also |
| 12 |
> provide $KV_MAJOR etc etc. Regardless of numbers, where do you feel is the |
| 13 |
> better place for parsing the kernel version details? |
| 14 |
|
| 15 |
You cut out my next line saying "Does portage use ${KV} internally?" |
| 16 |
which was also part of the point ;) |
| 17 |
|
| 18 |
Anyways, what I was trying to say was - if 729 ebuilds currently rely on |
| 19 |
knowing the version of the installed Linux kernel source I think this |
| 20 |
information should be available through portage itself, and not an |
| 21 |
eclass. |
| 22 |
|
| 23 |
> I'm in favour of the eclass, I don't think it makes sense for portage to find |
| 24 |
> the version string on emerge of every package. And, in situations like this |
| 25 |
> (with localversion appearing) its easier for us to extend the code to support |
| 26 |
> it. |
| 27 |
|
| 28 |
This is where the question above (does portage use ${KV} internally?) |
| 29 |
becomes important. If portage uses ${KV} internally it can not be |
| 30 |
supplied by an eclass. |
| 31 |
|
| 32 |
Could one of the portage devs please shed some light on this? |
| 33 |
|
| 34 |
Sincerely, |
| 35 |
Brix |
| 36 |
-- |
| 37 |
Henrik Brix Andersen <brix@g.o> |
| 38 |
Gentoo Linux |
Archives