Yeah, it's finally done. It needs a lot of testing though. If you find any bugs, or want to have certain features added to this ebuild, post them here. Be my guests, -phoen][x-
Hiya, Nice ebuild :-) 1. Q: does the default branch "winex-2-1" mean winex 2.1 + bugfixes, i.e. stable branch? 2. Were you allowed by people like Seemant to add the cvs ebuild to portage because the stable branch is default, or regardless? What's the policy? You can guess what I have in mind... :-) (Not for the near future though) 3. The ebuild adds -dP to cvs parameters, this is redundant since -dP is in the default parameters in the eclass. (?) Also I should add branch support via an ECVS_BRANCH var to the eclass at some point to make things nice...
Hey dan, spooky linewrapping.. 1) yeah, "winex-2-1" is the current stable branch while "winex" is the current development branch (from what i can tell, maybe the guys at transgaming changed it again, heh) 2) I didnt talk to seemant until now. This is a very early test of the winex-cvs package, it will most likely never go into tree (unmasked, that is). The good thing about the cvs ebuilds is that it's really simple to update the package to a newer version (one "emerge winex-cvs" and you are done) - the bad thing is that bugs are kinda hard to reproduce. Even if this is the stable winex-2.1 branch, who could guarantee that it'll never break? Nobody, right. Thats why i dont like the idea of unmasking it. The second thing is that portage will not update cvs packages - we would have to bounce the ebuild to a newer version in order to force portage to update it. That makes the whole idea quite useless. :) What would you suggest? 3) Thats from the cvs.eclass: # cvs options given after the command (i.e. cvs update foo) # don't remove -dP or things won't work [ -z "$ECVS_CVS_OPTIONS" ] && ECVS_CVS_OPTIONS="-dP" so, if i overwrite ECVS_CVS_OPTIONS in my ebuild, i have to append a "-dP" to it, no? Correct me if i'm wrong - i'm quite the type of procedural programmer. :) ECVS_BRANCH would be nifty, yeah. -phoen][x-
2. Well, of course I don't suggest unmasking it, but I'd like to see my kde cvs ebuilds in potrage (masked) one day :-) We had at least 3 or 4 discussions about cvs ebuilds and their possible versioning schemes/portage update logic on -core over the last six months. drobbins agreed that it would be nice to have portage support for cvs ebuilds in principle, but this was labelled potage2 stuff in the 1.x days, and since portage2 was effectively cancelled and portage1 got a new version number, we'll have to wait for portage3. 3. Well, with eclasses the logical thing for you to do would be ECVS_CVS_OPTIONS="$ECVS_CVS_OPTIONS -rFoo" or whatever your custom parameters are, adding to the eclass-defined parameters but not replacing them. You need to do that after inheriting cvs.eclass because the eclass sets the variables, it doesn't add to them - exactly to allow this distinction. ECVS_BRANCH is easy to add, it just puts a -r$ECVS_BRANCH in the cvs call and possibly something in the generated CVS/ files (?). Will do.
Whats the big problem of adding the kde-cvs ebuilds to the tree? As long as they are masked, they wont break anything. The update-anomaly should be no problem for us then. Anyways, I'll have to talk to seemant today. You are right about the ECVS_CVS_OPTIONS thingy. I'll change it once i'm back home. Anyways, back to work. -phoen][x-
Hey dan, seemant said that its okay to put cvs ebuilds into the tree as long as they stay masked. Maybe you should doublecheck it with him, but i think you could give the kde-cvs-ebuilds a try. :) -phoen][x-
Please forgive my ignorance.... >>> emerge app-emulation/winex-cvs-2.1 to / >>> Unpacking source... * Running cvs -q -f -z4 update -dP -rwinex-2-1 with cvs.winex.sourceforge.net:/cvsroot/winex for wine/... /usr/sbin/ebuild.sh: cvs: command not found !!! ERROR: The ebuild did not complete successfully. !!! Function cvs_fetch, Line -7315, Exitcode 127 !!! died running cvs update
Hmmm, i don't get the idea of that. Correct me if i'm wrong, but a look at cvs.eclass tells me that dev-util/cvs gets always appended to DEPEND. So i ran "emerge -C cvs" on this box and unmasked winex-cvs. "emerge -p winex-cvs" doesn't show me a cvs dependency. Here's some output for you: /------------------------------------------------------------------------- | whb01694 root # emerge -s cvs | [...] | * dev-util/cvs | Latest version available: 1.11.2 | Latest version installed: [ Not Installed ] | Homepage: http://www.cvshome.org/ | Description: Concurrent Versions System - source code revision control tools | [...] | whb01694 root # emerge -p winex-cvs | | These are the packages that I would merge, in order. | | Calculating dependencies ...done! | [ebuild N ] app-emulation/winex-cvs-2.1 to / | | whb01694 root # emerge winex-cvs | Calculating dependencies ...done! | >>> emerge app-emulation/winex-cvs-2.1 to / | >>> Unpacking source... | * Running cvs -q -f -z4 update -dP -rwinex-2-1 with cvs.winex.sourceforge.net:/cvsroot/winex for wine/... | /usr/sbin/ebuild.sh: cvs: command not found | | !!! ERROR: The ebuild did not complete successfully. | !!! Function cvs_fetch, Line -7274, Exitcode 127 | !!! died running cvs update | \-------------------------------------------- So a workaround would be to make winex-cvs depend on cvs itself. Therefore, you have to modify the ebuild like that: DEPEND="virtual/x11 sys-devel/gcc sys-devel/flex dev-util/yacc dev-util/cvs >=media-libs/freetype-2.0.0 dev-lang/tcl dev-lang/tk opengl? ( virtual/opengl ) cups? ( net-print/cups )" Dan, this looks kinda odd to me. Do you see another solution for this problem? -phoen][x-
The answer is simple. In the ebuild, you first inherit cvs (and cvs is added to DEPEND). Then you set DEPEND=whatever overwriting any changes made by the eclass. Changing this to DEPEND="$DEPEND ..." fixes the problem. Oh and: with cvs in DEPEND, the RDEPEND="$DEPEND" line isn't very correct. I've fixed that too. Simply call newdepend() (which lives in ebuild.sh) to add your list of deps to both DEPEND and RDEPEND without overwriting them. This is an obvious fix so I'm committing it.
Looks like winex-cvs is damn stable. I'll close this bug now. Thx for your help dan, -phoen][x-
