| 1 |
On Friday 06 July 2007, Steve Long wrote: |
| 2 |
> Mike Frysinger wrote: |
| 3 |
> >> > this would be for 2007.1+ profiles and we can leave the old things in |
| 4 |
> >> > place until we phase out 2007.0 and older completely |
| 5 |
> >> |
| 6 |
> >> This is actually something I was already planning on working on setting |
| 7 |
> >> up. To avoid conflicting with the current profiles, I was planning on |
| 8 |
> >> making a new profile tree. I wasn't planning on using it for 2007.1's |
| 9 |
> >> official media, though, but rather just /experimental stuff, since I'd |
| 10 |
> >> rather get much more testing on it before it goes "live" as the default. |
| 11 |
> > |
| 12 |
> > you proposing we rearchitect it all or just for testing purposes before |
| 13 |
> > going live ? |
| 14 |
> |
| 15 |
> Er I thought the whole point of a portage tree on the system was to allow |
| 16 |
> people to mess about with stuff.. Even if not, is there any real conflict |
| 17 |
> in doing both; ie rearchitect on an offline version, test properly and then |
| 18 |
> switch to new branch? However long releng need is however long they need |
| 19 |
> aiui. After the stress of the last few months, is it really such a big deal |
| 20 |
> if there's no 2007.1- it's not like anyone needs to reinstall is it? |
| 21 |
|
| 22 |
you misinterpret ... me saying "going live" means "release and expect people |
| 23 |
to switch to using it on stable systems" |
| 24 |
|
| 25 |
> Speaking of stuff that's holding you back, what's going on with the PMS? |
| 26 |
> Aiui several changes to portage await EAPI=1 and i don't see any sign of |
| 27 |
> EAPI=0 being finalised. The cia project page shows no commits since April. |
| 28 |
> Has it switched to another src-tracker? |
| 29 |
|
| 30 |
nothing i'm prosing is held back by EAPI=1 |
| 31 |
|
| 32 |
> > i can see both ... |
| 33 |
> > profiles/frags/ |
| 34 |
> > libc/uclibc/ |
| 35 |
> > libc/gclibc/ |
| 36 |
> > arch/amd64/ |
| 37 |
> > arch/sh/ |
| 38 |
> > kernel/linux/ |
| 39 |
> > kernel/bsd/ |
| 40 |
> > kernel/bsd/freebsd/ |
| 41 |
> > kernel/bsd/openbsd/ |
| 42 |
> > |
| 43 |
> > profiles/default-linux/amd64/parent |
| 44 |
> > ../../frags/arch/amd64 |
| 45 |
> > ../../frags/kernel/linux |
| 46 |
> > ../../frags/libc/glibc |
| 47 |
> > .. |
| 48 |
> |
| 49 |
> Makes a lot of sense when you lay it out like that. Is there a namespace |
| 50 |
> issue with profiles/{libc,arch,kernel}? |
| 51 |
|
| 52 |
i thought it looked ugly to have them in the top level. the idea with frags |
| 53 |
is that by name only, it should be easy to see users arent supposed to be |
| 54 |
using the profile ... |
| 55 |
-mike |
Archives