| 1 |
On 25 Jul 2004, at 03:26, Jason Stubbs wrote: |
| 2 |
|
| 3 |
> The real problem is that nobody (if I am like everybody else) has |
| 4 |
> heard about |
| 5 |
> this stuff except those that are following the macos movement. If you |
| 6 |
> had |
| 7 |
> announced your plan to inject everything in MacOS and keyword ebuilds |
| 8 |
> on the |
| 9 |
> assumption that those packages are available, many people could have |
| 10 |
> told you |
| 11 |
> that the issues that are happening currently would occur. More |
| 12 |
> importantly, |
| 13 |
> solutions would have been able to be created before the current issues |
| 14 |
> became |
| 15 |
> issues. |
| 16 |
|
| 17 |
The MacOS project was announced one year ago. One single portage |
| 18 |
feature that still isn't implemented held the project up for that long. |
| 19 |
It's a relatively simple feature compared to the other requirements I |
| 20 |
have for a next generation portage. What MacOS is doing right now is |
| 21 |
moving forward and identifying all MacOS related issues, creating bug |
| 22 |
reports for them and we try to do our best finding both long term and |
| 23 |
short term solutions. We can't afford to be put on hold for another |
| 24 |
year, unfortunately. |
| 25 |
|
| 26 |
>> Why does repoman/linux think the dependency graph for macos is broken. |
| 27 |
> |
| 28 |
> Because it is. |
| 29 |
|
| 30 |
By design. |
| 31 |
|
| 32 |
> So then you are trying to use one keyword to describe both a situation |
| 33 |
> where |
| 34 |
> all base packages are available and one where they aren't? |
| 35 |
|
| 36 |
darwin keyword + darwin profiles -> from scratch approach, |
| 37 |
bootstrapping, livecds, nothing which depends on xcode |
| 38 |
macos keyword + macos profiles -> repository of mac OS X compatible |
| 39 |
apps, supports forced overwrites, supports prefixed installs, no |
| 40 |
bootstrapping |
| 41 |
|
| 42 |
anything that is darwin compatible is macos compatible, but not the |
| 43 |
other way around. |
| 44 |
|
| 45 |
>> Since repoman doesn't complain about macos under macos (it must be |
| 46 |
>> broken or somehow take into account injected packages when doing |
| 47 |
>> --emptytree), I prefer this option. It's also the least amount of |
| 48 |
>> work. |
| 49 |
> |
| 50 |
> Does it complain when the patch Travis mentioned is in place? |
| 51 |
|
| 52 |
I'll try. |
| 53 |
|
| 54 |
I must say that repoman doesn't work out of the box on any of my |
| 55 |
computers. You're free to try it yourself, I was quite surprised to see |
| 56 |
repoman being happy about macos keywords on my x86, ppc and sparc |
| 57 |
machines. All running latest portage development release .51_pre13. |
| 58 |
|
| 59 |
>> 2. make repoman macos aware |
| 60 |
> |
| 61 |
> s/make repoman macos aware/include support in ALL of portage/ |
| 62 |
|
| 63 |
That's the plan. There will be code, no worry. But until there's code, |
| 64 |
we use the cleanest possible short-term solution for various issues. |
| 65 |
|
| 66 |
>> This requires new portage features. Adding another file to the |
| 67 |
>> profiles, I can think of at least 2 portage feature requests that |
| 68 |
>> require adding another file to the profiles, so this can't be a short |
| 69 |
>> term solution. |
| 70 |
> |
| 71 |
> Why wasn't this suggested months ago? A feature such as this (which |
| 72 |
> isn't hard |
| 73 |
> to implement btw) could allow you to not inject everything and be able |
| 74 |
> satisfy repoman as well. It would also be useful in separating your |
| 75 |
> two types |
| 76 |
> of macos users into separate profiles. |
| 77 |
|
| 78 |
When I openened the bug about persistent packages, somebody masked it |
| 79 |
as a DUP for a bug numbered somewhere between 11000 - 12000 (we're at |
| 80 |
54000 right now). I'm assuming similar feature requests have been |
| 81 |
waiting for some time. |
| 82 |
|
| 83 |
Best regards, |
| 84 |
|
| 85 |
Pieter Van den Abeele |
| 86 |
|
| 87 |
|
| 88 |
-- |
| 89 |
gentoo-dev@g.o mailing list |
Archives