| 1 |
> This has been brought up before in the past and been shot down, but I'll humor |
| 2 |
> you. If support for this were to be added into Portage, there would be a few |
| 3 |
> things to think about: |
| 4 |
> |
| 5 |
> 1) this will cause a performance hit no matter how it is done |
| 6 |
> 2) how will Portage know the difference between a package and another |
| 7 |
> sub-category when it is walking the tree? It could do something like walking |
| 8 |
> all the way to the end of the category/sub-category/sub-category tree until |
| 9 |
> it finds .ebuild files and then backing up a level or 2 to determine the |
| 10 |
> category, but again this would cause an enormous performance hit due to the |
| 11 |
> additional required I/O. |
| 12 |
> 3) the many additional directories would cause an 'emerge sync' to take |
| 13 |
> longer than it does now. |
| 14 |
> |
| 15 |
> Basically, you'd be pissing everyone off with little benefit (except maybe to |
| 16 |
> developer sanity). Keep in mind that I probably have absolutely no idea what I'm |
| 17 |
> talking about and nothing I say should be accepted as fact without verifying it |
| 18 |
> elsewhere. |
| 19 |
> |
| 20 |
> -- |
| 21 |
> Andrew Gaffney |
| 22 |
> Network Administrator |
| 23 |
> Skyline Aeronautics, LLC. |
| 24 |
> 636-357-1548 |
| 25 |
> |
| 26 |
> -- |
| 27 |
> gentoo-dev@g.o mailing list |
| 28 |
> |
| 29 |
> |
| 30 |
|
| 31 |
Why does this necessarily have to change the portage directory structure? |
| 32 |
|
| 33 |
I think this is a good idea to, but why not implement a secondary |
| 34 |
browsing interface which could use these categories and just map to |
| 35 |
ebuilds. With this strategy, even if a package fell into two |
| 36 |
categories, it could be put into both. This could also lead to any |
| 37 |
number of more pretty features. |
| 38 |
|
| 39 |
-- |
| 40 |
gentoo-dev@g.o mailing list |
Archives