currently, based on what i can divulge, the syck compile install script na
currently, based on what i can divulge, the syck compile install script naïevely assumes you have only 1 copy of php on your system, and the phpize script merely executes the currently selected one. I for example, have both php4 and php5 on my system, and as php4 was the most recently merged one, syck only built for php4. So i request/suggest one of the following possible solutions #1 =================================== either a dev-php4/syck and dev-php5/syck ebuild ( overkill, but easy to implement ) which simply does CURRENT_PHP=`php-select php-devel | sed "s|^.*/usr/lib/||;s|/bin.*$||" | head -n 1` php-select php-devel php5 ( or php4 as the case may be) does its stuff, and then php-select php-devel ${CURRENT_PHP} ======================================== #2 php4 and php5 USE flags which do the above execpt inside the one file #3====================================== Like above, execpt do some fancy stuff to identify what versions of php are available, and then do as above ;) In the mean time people will just have to emerge twice and touch the one of the php instances to prevent it getting removed between merges, but I think a nicer solution can be provided :) oh, and while your there, making a standard syck.ini for the /etc/php/whatever-php/ext dirs would probably be a nice feature too :) (yeah, i know its an only 1 line of code file .. but still, gentoo is cool and we can do these things for the users to make their life easier ) thanks people :)
Eh, the php bindings should use php-ext-source-r1 eclass.
BTW, the current ebuild compiles w/ USE=php for you? The only thing I get is <snip> checking for syck files in default path... not found configure: error: Please reinstall the syck distribution </snip>
(In reply to comment #2) > BTW, the current ebuild compiles w/ USE=php for you? The only thing I get is > > <snip> > checking for syck files in default path... not found > configure: error: Please reinstall the syck distribution > </snip> > syck 0.55-r1 is currently installed on my box against both dev-lang/php-4.4.2-r6 and dev-lang/php-5.1.4-r6 using the the "touch to prevent it getting cleaned" trick I mentioned using :) and this is from my phpinfo output ( annotated by hand to look pretty ): [ syck ] [ syck support | enabled ] so i take that to mean something is working :)
(In reply to comment #2) Jakub, what you need to do is emerge dev-libs/syck with no use flags (ie. USE='-*') and then emerge again with flags the way you want them. I believe this will also be an issue when upgrading syck, where the php/python modules may end up compiled against the _previous_ syck version, not the newest one .
(In reply to comment #4) > (In reply to comment #2) > > Jakub, what you need to do is emerge dev-libs/syck with no use flags (ie. > USE='-*') and then emerge again with flags the way you want them. This is severely broken and I urge the maintainer to drop the bindings. A separate ebuild for php bindings is definitely required, the others are not PHP herd's business. Also it'd be nice to ask php folks about this in cases when the maintainer is not sure how to handle such stuff properly. > I believe this will also be an issue when upgrading syck, where the php/python > modules may end up compiled against the _previous_ syck version, not the newest > one . In that case, ditto as above.
To make a long story short: I guess we need a PHP-herd-blessed ebuild for syck's PHP bindings, and the same thing from the Python herd.
Yuval, How simple is it to split this into multiple ebuilds (one for vanilla, one for php support, one for python support)? Or is it simpler to keep them together? Not sure I follow asking another herd to use a language USE flag - if that's the case, then I think we should be po'd at all the ebuilds using perl without telling us (just saying :) If php and python folks are really that livid that syck has bindings for each, i'll take the heat, i'm yuval's mentor/sponsor/gatekeeper and condoned what he did after testing to make sure it worked.
(In reply to comment #7) > Yuval, > > How simple is it to split this into multiple ebuilds (one for vanilla, one for > php support, one for python support)? Or is it simpler to keep them together? Very simple, basically just split the part of src_compile() that builds the respective binding and depend on syck. This will also fix the issue that the binding don't actually compile, as they need syck installed already - see Comment #4. Well, this needs to be fixed upstream anyway because it can lead to other issues, like linking against old syck version. > Not sure I follow asking another herd to use a language USE flag - if that's > the case, then I think we should be po'd at all the ebuilds using perl without > telling us (just saying :) Michael, the fact is that the ebuild is broken ;) We will be happy to help anyone to implement PHP bindings in their ebuilds properly (someone's hanging out on #gentoo-php all the time). We need one ebuild for PHP4 and one for PHP5, otherwise it won't work correctly for people with multiple PHP versions installed. I'll attach an ebuild for testing shortly.
Created attachment 96150 [details] dev-php[45]/syck-php-bindings-0.55.ebuild Stick into dev-php4/ for PHP4, dev-php5/ for PHP5. ;)
Created attachment 96151 [details] dev-libs/syck-0.55-r2.ebuild dev-libs/syck ebuild without PHP bindings... Fixed redundant ruby dependency w/ USE="-ruby". I didn't try other bindings, if Comment #4 is valid for them as well, they'll also have to be moved to external ebuilds.
OK, python and ruby bindings compile fine even without syck installed beforehand. This can be closed once the above is committed. @yuval - could you please tell upstream that their php bindings are broken? :)
0.55-r2 is in CVS. BUT just after I committed, I went to syck's website in order to report upstream, and there's a headline that says "Syck Now Included with Ruby 1.8.0!" I'll check out if it's true; maybe we don't need the ruby flag either...
Created attachment 96156 [details] syck-0.55-r3.ebuild (In reply to comment #12) > 0.55-r2 is in CVS. > BUT just after I committed, I went to syck's website in order to report > upstream, and there's a headline that says "Syck Now Included with Ruby 1.8.0!" Err, LOL. OK... - ruby bindings dropped - reinstate php USE flag, PDEPEND on syck-php-bindings - block the broken version only when USE=php is set You might want to drop -r[12] once this one is in. ;)
Created attachment 96157 [details] dev-php[45]/syck-php-bindings-0.55.ebuild - blockers need to be mutual ;)
(In reply to comment #13) > - ruby bindings dropped Did you make sure it works in Ruby? My Ruby skills are bad, but I'll check it later. > You might want to drop -r[12] once this one is in. ;) I'll do it the minute -r3 is in CVS, which I won't commit until dev-php[45]/php-syck-bindings are in CVS.
(In reply to comment #15) > (In reply to comment #13) > > - ruby bindings dropped > > Did you make sure it works in Ruby? It's already there: # equery b `rlocate syck.so` [ Searching for file(s) /usr/lib/debug/usr/lib/ruby/1.8/i686-linux/syck.so.debug,/usr/lib/ruby/1.8/i686-linux/syck.so in *... ] dev-lang/ruby-1.8.5 (/usr/lib/debug/usr/lib/ruby/1.8/i686-linux/syck.so.debug) dev-lang/ruby-1.8.5 (/usr/lib/ruby/1.8/i686-linux/syck.so) > > You might want to drop -r[12] once this one is in. ;) > > I'll do it the minute -r3 is in CVS, which I won't commit until > dev-php[45]/php-syck-bindings are in CVS. Just commit it and stick yourself as maintainer, w/ php as herd. Be sure to commit to both dev-php4 and dev-php5. Thanks.
Any update on this? I've verified Jakub's ebuilds and they are correct, so just add those into the tree as explained, and be sure to add yourself as maintainer and php as herd for the dev-php4/ and dev-php5/ ones. Best regards, CHTEKK.
In CVS. Sorry it took time, I moved to a new apartment and a gazillion other things. Please reopen if there's anything wrong. (BTW, Jakub's ebuild for -r3 has a wrong PDEPEND for php-syck-bindings instead of syck-php-bindings, I have no idea how it worked for you, Luca)
