| 1 |
On 26 June 2011 05:29, Ulrich Mueller <ulm@g.o> wrote: |
| 2 |
>>>>>> On Sat, 25 Jun 2011, Maciej Mrozowski wrote: |
| 3 |
> |
| 4 |
>> Assuming package names are unique identifiers, tags are not |
| 5 |
>> necessary to be available for ebuild.sh so metadata.xml is the best |
| 6 |
>> place. |
| 7 |
> |
| 8 |
> But we know that package names are _not_ unique. There are many cases |
| 9 |
> in the Portage tree where two or even more packages have the same |
| 10 |
> name. Categories are there to avoid such collisions. |
| 11 |
> |
| 12 |
> With multiple overlays/repositories instead of one monolithic Portage |
| 13 |
> tree, the collision issue gets even worse if you have a flat |
| 14 |
> namespace. |
| 15 |
> |
| 16 |
> Ulrich |
| 17 |
> |
| 18 |
> |
| 19 |
|
| 20 |
At present, this exists because we use categories as a the primary way |
| 21 |
for a *user* to find the package. Our current collision avoidance |
| 22 |
strategy is targeted at not confusing our *user*. |
| 23 |
|
| 24 |
However, in the proposed strategy, package names themselves are not |
| 25 |
*users* primary interface. "tags" and other metadata are intended as |
| 26 |
the users primary interface. |
| 27 |
|
| 28 |
Package names themselves can be thusly arbitrary , and could be a SHA |
| 29 |
sum or something obscure, as long as all internals and dependencies |
| 30 |
used the same arbitrary name, things would work as intended. |
| 31 |
|
| 32 |
There is one remaining downside to the flat topology however, and that |
| 33 |
is it may hamper our move to git. |
| 34 |
|
| 35 |
I was thinking that what could be done is have seperate submodules or |
| 36 |
whathave you for various categories to somewhat ease the load of "A |
| 37 |
full checkout of the tree going back for all time can be bloody huge |
| 38 |
and slow" , but without categorical subtrees that approach will be |
| 39 |
less viable. |
| 40 |
|
| 41 |
Although, this what currently seems like a disadvantage could be used |
| 42 |
to an advantage perhaps, with the possible idea of "meta trees" of |
| 43 |
some description. If we relinquish the hold we have on symlinks, a few |
| 44 |
interesting options become available. |
| 45 |
|
| 46 |
Different Herds could have their own subtrees in |
| 47 |
|
| 48 |
/projects/herd/<x> |
| 49 |
|
| 50 |
and a tool could be used to symlink the contents of herd specific |
| 51 |
subtrees to the ebuilds folder. |
| 52 |
|
| 53 |
/ebuild/<pn> --> /projects/herd/<herdname>/<pn> |
| 54 |
|
| 55 |
And the tool can inform herds when they add a new package that |
| 56 |
conflicts with the name of an existing one so it can be disambiguated |
| 57 |
before the tree propagates to users. |
| 58 |
|
| 59 |
Continuing on that line of thought and you get even more interesting |
| 60 |
ideas, like introducing a "merge mask" file, which allows people to |
| 61 |
work on stuff in the herd tree , and indicate that their |
| 62 |
files/packages are not fit for integration with the main-tree yet, |
| 63 |
somewhat bridging the gap we presently have between "Development" |
| 64 |
overlays and the current main tree. |
| 65 |
|
| 66 |
This could in turn make collaboration even easier, as dev branches |
| 67 |
will be able to go nuts with all sorts of random contributions, and |
| 68 |
when its deemed fit for public consumption and testing remove the |
| 69 |
package from the merge mask and its there. |
| 70 |
|
| 71 |
</early morning coffee fuelled idea session> |
| 72 |
|
| 73 |
-- |
| 74 |
Kent |
| 75 |
|
| 76 |
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, |
| 77 |
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" |
| 78 |
|
| 79 |
http://kent-fredric.fox.geek.nz |
Archives