It seems sys-apps/file-4.08 is keyworded ppc-macos but would overwrite system-provided files were it not for FEATURES="collision-protect". Ideas?
I sent it to macos@g.o last Sunday (sys-devel/flex and sys-apps/file) and pvdabeel posted his opinion about it. "In case of flex: if our flex provides the same funcitonality of apples flex (just a newer version, whatever), flex can go in macos, or ~macos but needs to be added to the provided file." Replace "flex" with "file". However, I also think it is good to know what package overwrites system-provided files (according to pvdabeel, packages could be keyworded ppc-macos even when they overwrite system-provided files).
"according to pvdabeel, packages could be keyworded ppc-macos even when they overwrite system-provided files" I'm not sure this is such a great decision - I must've missed the email discussion somewhere along the line. What about people who don't want to overwrite files? It's a bit annoying to spend time compiling a package just to have it fail because of collision protect. For example, glib2 (up until yesterday when I fixed it) had a collision protect error because of a manpage. It was rather annoying to find that out AFTER compiling glib. If we're going to allow packages to be keyworded ppc-macos even though they overwrite system files, there should be some way to easily tell whether or not a given package falls into this category before emerging it. (for the average -- not power -- user.) Secondly, the problem I have with file is that it comes up in emerge -u world. Shouldn't the default behavior of package.provided be NOT to upgrade? If so, can we fix this; if not, why not?
as an alternative, what if packages that overwrite apple provided files were keyworded ppc-darwin, that way the "power" users who want to break os x can simply put that keyword in their make.conf
Sorry if I miss some discussion (or I assumed such a discussion being held), because I haven't read the last meeting log (could some of you post it to macos@g.o or core list?). I agree with you, j4rg0n, but `emerge -u world` shows sys-apps/file (and sys-devel/flex) to be upgraded iff I use stacked profile, default-macos/ppc/10.3 (I post it to macos@g.o, I guess you read it already). Flat profile, default-macos-10.3 doesn't show them. btw, Kito's suggestion seems good to me. (but we might be abusing "ppc-darwin" keyword if we do so)
I don't think it would be abusing the ppc-darwin keyword at all as anything that is masked ppc-darwin will build on pure darwin or os x, this would obviously not work for any package that would modify/overwrite the proprietary os x libs, but I see no problem with using the ppc-darwin keyword for the open source components.
I'm definately for the use of a different keyword, just not necessarily the ppc-darwin one. If ppc-darwin seems to be the consensus, and it's ok on the QA front, then let's do it. Anyone else have thoughts on this? Let's get a ruling on this...
The reason why I said abusing is that under current Gentoo policy we cannot mark anything we acutally test. Given that, as I do not run pure Darwin but Mac OS X I should test the ebuild on pure Darwin before marking it ppc-darwin. As kito said in Comment #5, anything that runs on ppc-darwin (theoretically) can be marked ppc-darwin and ppc-macos, but not the other way around.
Great, so can we change the keyword on file to ppc-darwin, instead of ppc-macos? Same with flex IIRC.
Yes and no; because you need to test the ebuild on ppc-darwin. Once you set up ppc-darwin chroot and tested it on that environment, it's okay to keyword it (~)ppc-macos. Someone told me he had amd64 box to test amd64 keyword while he created 32bit chroot environment to test x86. Same should apply to ppc-macos/ppc-darwin. kito said that we can test ppc-darwin with a 4gb disk image, so if you are going to keyword it ppc-darwin please install ppc-darwin and test.
does anyone have a working ppc-darwin system up yet? if so, can they test it asap? if not, as long as we all agree that the ppc-macos keyword needs to be dropped in these ebuilds, then can we drop them and add the ppc-darwin keywords when it can be tested?
perhaps i misunderstood what was written earlier; after having re-read the bug, i get the feeling that some of us think that it's okay to keyword anything ppc-macos that is already keyworded ppc-darwin. This is clearly _not_ the case. ppc-macos has an already-installed set of packages that may collide with any given ebuild, and these packages should not be keyworded ppc-macos. The reverse, however seems to me to be true. Please correct me if i'm wrong. As far as I understand, there should be no package that compiles and runs on ppc-macos that does not compile and run on ppc-darwin. Because of this, it should be clear that keywording anything ppc-macos is analogous to keywording the same thing ppc-darwin, with the exception that it is untested on ppc-darwin.
Well, design/philosophical issues aside, i think you have it backwards. Any package that compiles and runs on ppc-darwin should behave exactly the same on ppc-macos. The opposite is definitely not true. ppc-macos ships with countless proprietary/closed source libs and frameworks that darwin itself will never have. I don't have a solution to this problem yet, but I think making every single package that would overwrite macos supplied files into a g-util would get very ugly and convoluted very fast. The implementation of PATHSPEC could of course solve this problem for people that want fink-esque behaviour, but thats waaaay out of my jurisdiction at this point, and it seems like its not a very pressing issue for the gentoo 'higher ups' , so we can't really rely on that to be the solution.
Well, if everything that runs on ppc-darwin runs on ppc-macos, then I don't see why we need to keyword things that will overwrite macos system files as ppc-macos. We can simply keyword them ppc-darwin, and if macos people want to overwrite system files, then they can turn off collision protect and accept both ppc-darwin and ppc-macos. So again, I repeat my request, can we please remove the ppc-macos keyword from both file and flex and close out this bug?
I'm totally ok with removing ppc-macos(and macos) keyword from both packages (if it doesn't break our tree). However, adding ppc-darwin keyword to them is a different story. It may or may not break ppc-darwin enviroment (I don't know because I cannot test), so we better not add ppc-darwin keyword for the time being, right?
"It's a bit annoying to spend time compiling a package just to have it fail because of collision protect." Mildly OT here, but if you have FEATURES="buildpkg", portage saves the binpkg prior to attempting a merge (technically it tries merging the binpkg rather then a transfer from /usr/portage/*/image)... either way, for those who've hit collisions, you still have the tbz2 created if you want/need it.
Since no one has commented on this bug saying the keywords should not be removed, I am removing them right now. I am also opening two new bugs for testing of file and flex on ppc-darwin as was suggested in this bug.
Closing out bugs that've been resolved for a while now...
