.deb packages for PHP6 - Ubuntu

This is a discussion on .deb packages for PHP6 - Ubuntu ; Hi all Does anyone know if there are deb packages available for PHP6? And, if so, where to find them? Thanks, Daniel...

+ Reply to Thread
Results 1 to 5 of 5

Thread: .deb packages for PHP6

  1. .deb packages for PHP6

    Hi all

    Does anyone know if there are deb packages available for PHP6? And, if so,
    where to find them?

    Thanks,
    Daniel

  2. Re: .deb packages for PHP6

    On Thu, 16 Oct 2008 17:23:16 +0200
    Daniel Smedegaard Buus wrote:

    > Does anyone know if there are deb packages available for PHP6? And,
    > if so, where to find them?


    I doubt there are any packages of PHP 6 at this point because PHP 6 is
    nowhere close to release.

    However, you can download the PHP 6 source code snapshot[1] and build
    it and subsequently install it in /opt (or wherever you see fit, just
    *not* in /usr unless you install it in /usr/local). Then you can
    configure an already-existing Apache server (or FastCGI, or however
    you're accessing PHP) to use PHP 6 instead of whatever the current PHP
    is on your system.

    Also, the download I linked to is just the current snapshot as of the
    time I wrote this message. The latest information can always be found
    on the PHP Snapshots page.[2]

    --- Mike

    [1] http://snaps.php.net/php6.0-200810161630.tar.bz2
    [2] http://snaps.php.net/

    --
    My sigfile ran away and is on hiatus.


  3. Re: .deb packages for PHP6

    Michael B. Trausch wrote:

    > On Thu, 16 Oct 2008 17:23:16 +0200
    > Daniel Smedegaard Buus wrote:
    >
    >> Does anyone know if there are deb packages available for PHP6? And,
    >> if so, where to find them?

    >
    > I doubt there are any packages of PHP 6 at this point because PHP 6 is
    > nowhere close to release.
    >


    Hi Mike, thanks for replying

    You seem to be right, but I was hoping not, which is why I was asking here,
    maybe someone knew of a secret place

    > However, you can download the PHP 6 source code snapshot[1] and build
    > it and subsequently install it in /opt (or wherever you see fit, just
    > *not* in /usr unless you install it in /usr/local). Then you can
    > configure an already-existing Apache server (or FastCGI, or however
    > you're accessing PHP) to use PHP 6 instead of whatever the current PHP
    > is on your system.
    >


    I've been trying that, actually. I'm a bit shabby at this, I've come as far
    as to satisfying needed dependencies (libxml2, apxs2, icu4 etc.), but I
    just tried making a checkinstall deb package, which fails with

    ========================= Installation results ===========================
    Installing PHP SAPI module: apache2handler
    /usr/share/apache2/build/instdso.sh
    SH_LIBTOOL='/usr/share/apr-1.0/build/libtool'
    libphp6.la /usr/lib/apache2/modules
    /usr/share/apr-1.0/build/libtool --mode=install cp
    libphp6.la /usr/lib/apache2/modules/
    cp .libs/libphp6.so /usr/lib/apache2/modules/libphp6.so
    cp .libs/libphp6.lai /usr/lib/apache2/modules/libphp6.la
    libtool: install: warning: remember to run
    `libtool --finish /home/daniel/.applications/sources/php6/php6.0-
    200810161030/libs'
    chmod 644 /usr/lib/apache2/modules/libphp6.so
    apxs:Error: Activation failed for custom /etc/apache2/httpd.conf file..
    apxs:Error: At least one `LoadModule' directive already has to exist..
    make: *** [install-sapi] Error 1

    **** Installation failed. Aborting package creation.

    Restoring overwritten files from backup...OK

    Cleaning up...OK

    Bye.

    I've done the libtool --finish thing it asks for, but no donut as of yet :/

    I know PHP6 isn't near ready for mainstream yet, but I installed it in WAMP
    on my workplace Windows box, and it runs pretty great actually, so I wanted
    to try it on on my new Kubuntu installation. The reasons I want PHP6 is 1)
    Late static binding (I so much want to replicate what I've grown to love in
    Ruby on Rails) and 2) Real unicode support (this should've been here soooo
    long ago

    Anyways, I'm not giving up quite yet. I'll try to get rid of that error
    soon, but rigth now I think I'll relax with a couple of beers and a movie.
    I *am* on vacation, hehe

    Oh, btw, if you know of 5.3 deb packages existing anywhere, those'd be
    great, too, since they at least satisfy my wish no. 1 about late static
    binding

    Cheers,
    Daniel

    > Also, the download I linked to is just the current snapshot as of the
    > time I wrote this message. The latest information can always be found
    > on the PHP Snapshots page.[2]
    >
    > --- Mike
    >
    > [1] http://snaps.php.net/php6.0-200810161630.tar.bz2
    > [2] http://snaps.php.net/
    >



  4. Re: .deb packages for PHP6

    On Thu, 16 Oct 2008 21:38:28 +0200
    Daniel Smedegaard Buus wrote:

    > Michael B. Trausch wrote:
    > >
    > > However, you can download the PHP 6 source code snapshot[1] and
    > > build it and subsequently install it in /opt (or wherever you see
    > > fit, just *not* in /usr unless you install it in /usr/local). Then
    > > you can configure an already-existing Apache server (or FastCGI, or
    > > however you're accessing PHP) to use PHP 6 instead of whatever the
    > > current PHP is on your system.
    > >

    >
    > I've been trying that, actually. I'm a bit shabby at this, I've come
    > as far as to satisfying needed dependencies (libxml2, apxs2, icu4
    > etc.), but I just tried making a checkinstall deb package, which
    > fails with


    Don't use checkinstall, just install it using the standard "./configure
    && make && make install" process... that's far easier, really.
    Checkinstall is okay if you're making a quick local package to deploy
    to 50 different machines, but if you're going to use something like
    that in the first place, it'd be a good idea to use the Debian
    packaging tools to create Debian packages anyway, since they are *far*
    more flexible and robust (and handle strange situations like needing to
    alter config files automatically).

    I'd recommend doing something like:

    ./configure --prefix /opt/php6 && make && sudo make install

    And that way it's in its own space. Uninstalling is then as simple as
    undoing your own custom modifications to Apache's configuration file
    and then doing:

    rm -Rf /opt/php6

    .... which will remove the PHP 6 binaries from the system.

    >
    > ========================= Installation results
    > =========================== Installing PHP SAPI module:
    > apache2handler /usr/share/apache2/build/instdso.sh
    > SH_LIBTOOL='/usr/share/apr-1.0/build/libtool'
    > libphp6.la /usr/lib/apache2/modules
    > /usr/share/apr-1.0/build/libtool --mode=install cp
    > libphp6.la /usr/lib/apache2/modules/
    > cp .libs/libphp6.so /usr/lib/apache2/modules/libphp6.so
    > cp .libs/libphp6.lai /usr/lib/apache2/modules/libphp6.la
    > libtool: install: warning: remember to run
    > `libtool --finish /home/daniel/.applications/sources/php6/php6.0-
    > 200810161030/libs'
    > chmod 644 /usr/lib/apache2/modules/libphp6.so
    > apxs:Error: Activation failed for custom /etc/apache2/httpd.conf
    > file.. apxs:Error: At least one `LoadModule' directive already has to
    > exist.. make: *** [install-sapi] Error 1


    This looks like a PHP 6 issue. You'll need to read the docs for PHP 6
    to determine how to handle that. The solution is probably to manage
    the Apache configuration yourself, and there should be, I would
    presume, a method of installation available that permits you to do just
    that.

    >
    > I've done the libtool --finish thing it asks for, but no donut as of
    > yet :/
    >


    Messages like that usually are just output... "make install" will
    typically handle such things for you at the time of installation. If
    it doesn't, then the package itself is fatally broken: "make install"
    must give you a functional install, with the only thing expected to be
    missing being configuration.

    This is only slightly different if, say, doing something like
    installing in your home directory. If you are installing libraries in
    your home directory that you are looking to test, for example, then
    ldconfig will fail, and you will have to adjust the
    environment variable LD_LIBRARY_PATH to include the libraries that
    you've installed in your home directory before the system libraries.

    > I know PHP6 isn't near ready for mainstream yet, but I installed it
    > in WAMP on my workplace Windows box, and it runs pretty great
    > actually, so I wanted to try it on on my new Kubuntu installation.
    > The reasons I want PHP6 is 1) Late static binding (I so much want to
    > replicate what I've grown to love in Ruby on Rails) and 2) Real
    > unicode support (this should've been here soooo long ago


    Eh, it also has namespaces, as well (though 5.3 has those, too). I've
    developed PHP for a very long time. I am not not enthusiastic about
    the road that they're heading down with a great deal of the decisions
    that they are making, and I cannot fathom continuing to use it.
    They've decided, for example, to include APC in PHP 6 as a core
    feature. Why? APC isn't what's needed---it's a bandage to cover a
    problem that has grown along with PHP's support of object-oriented
    programming: the PHP compiler and the bytecode execution engine need to
    become two separate pieces of software.

    For example, If one could compile the scripts such that they were
    on-disk in compiled format, and then mod_php were to load the bytecode
    and execute _that_ (possibly caching the result itself, since it is
    rather easy to see when the mtime on the bytecode file changes), life
    would be a _great_ deal easier. It'd also be more efficient then
    keeping the scripts on-disk in their source code form, since PHP reads
    the source and compiles it to bytecode upon every page hit anyway,
    without APC.

    There are other bandages that they're applying, and they may work for
    some people, but I can't see myself using them when such things could
    be much more easily fixed at the source. Unicode support is great, for
    example: it should've been supported everywhere a long time ago. It's
    slower in PHP than plain ASCII support, and that is to be expected,
    though I expect that some large gains in performance will be necessary
    in PHP's handling of Unicode throughout its API: I read on one of the
    PHP developer's blogs (can't recall where ATM) that the Unicode support
    reduces string-heavy manipulation speeds by about 25%. Most PHP
    applications perform a *lot* of string manipulation, so this will be a
    very noticeable performance hit.

    >
    > Anyways, I'm not giving up quite yet. I'll try to get rid of that
    > error soon, but rigth now I think I'll relax with a couple of beers
    > and a movie. I *am* on vacation, hehe
    >
    > Oh, btw, if you know of 5.3 deb packages existing anywhere, those'd be
    > great, too, since they at least satisfy my wish no. 1 about late
    > static binding
    >


    I can't find any in PPAs or the like, and there don't appear to be any
    at backports.org. However, you should be able to take the PHP 5.2
    source package from a reasonably modern Ubuntu, and use the uupdate
    utility to update it to a PHP 5.3 snapshot, with modifications.

    Essentially, though, I am recommending that if you aren't going to be
    using the package manager and its utilities to create packages, that
    you install from source in the usual way for Unix-like systems and
    install the programs in their own trees as I pointed out above.
    Speaking from experience, this makes their management *much* easier.

    HTH,
    Mike

    --
    My sigfile ran away and is on hiatus.


  5. Re: .deb packages for PHP6

    Michael B. Trausch wrote:

    > Don't use checkinstall, just install it using the standard "./configure
    > && make && make install" process... that's far easier, really.
    > Checkinstall is okay if you're making a quick local package to deploy
    > to 50 different machines, but if you're going to use something like
    > that in the first place, it'd be a good idea to use the Debian
    > packaging tools to create Debian packages anyway, since they are *far*
    > more flexible and robust (and handle strange situations like needing to
    > alter config files automatically).
    >
    > I'd recommend doing something like:
    >
    > ./configure --prefix /opt/php6 && make && sudo make install
    >
    > And that way it's in its own space. Uninstalling is then as simple as
    > undoing your own custom modifications to Apache's configuration file
    > and then doing:
    >
    > rm -Rf /opt/php6
    >
    > ... which will remove the PHP 6 binaries from the system.
    >


    Hello again, Mike Thank you so much for your help. I'd completely
    forgotten how friendly and helpful people can be in the Linux world. Thanks
    for reminding me

    I really wanted to make the package to make removing everything again real
    easy. I see how putting it in /opt/php6 would make it easy to remove, but
    then I'd be scratching my head trying to figure out how to let "everyone"
    know that PHP6 was there

    Anyway, I gave up on the PHP6 thing. But I've been hacking away at making a
    PHP 5.3 package, and I just succeeded! Yay! After about 60 or 70 dev
    dependencies installed to satisfy .configure, studying the output of the
    5.2 php-config to replicate the relevant configure options of the official
    5.2 Ubuntu package, and patching a gdlib header file, I have successfully
    created and installed a 64-bit .deb package of PHP 5.3.0 alpha 3, and it's
    happily running along with Apache as we speak There's only one thing
    missing, and that's recode support. It simply refused to compile librecode
    together with mysql, and hey, I think I need MySQL more

    Only thing is, AFAICT, my package provides pretty much the same as all of
    the official, fragmented packages do. I have no clue as how to do this
    fragmentation myself (like making a php-pear or php-mysql package), so
    it'll be interesting to see how dependencies are handled once I want to
    install something that my package provides, but probably isn't "known", if
    you catch my drift

    >>
    >> ========================= Installation results
    >> =========================== Installing PHP SAPI module:
    >> apache2handler /usr/share/apache2/build/instdso.sh
    >> SH_LIBTOOL='/usr/share/apr-1.0/build/libtool'
    >> libphp6.la /usr/lib/apache2/modules
    >> /usr/share/apr-1.0/build/libtool --mode=install cp
    >> libphp6.la /usr/lib/apache2/modules/
    >> cp .libs/libphp6.so /usr/lib/apache2/modules/libphp6.so
    >> cp .libs/libphp6.lai /usr/lib/apache2/modules/libphp6.la
    >> libtool: install: warning: remember to run
    >> `libtool --finish /home/daniel/.applications/sources/php6/php6.0-
    >> 200810161030/libs'
    >> chmod 644 /usr/lib/apache2/modules/libphp6.so
    >> apxs:Error: Activation failed for custom /etc/apache2/httpd.conf
    >> file.. apxs:Error: At least one `LoadModule' directive already has to
    >> exist.. make: *** [install-sapi] Error 1

    >
    > This looks like a PHP 6 issue. You'll need to read the docs for PHP 6
    > to determine how to handle that. The solution is probably to manage
    > the Apache configuration yourself, and there should be, I would
    > presume, a method of installation available that permits you to do just
    > that.
    >


    Now that I've done the 5.3, I think I might actually be able to fix this...
    Hmmm... Maybe I should give it a try

    >> I know PHP6 isn't near ready for mainstream yet, but I installed it
    >> in WAMP on my workplace Windows box, and it runs pretty great
    >> actually, so I wanted to try it on on my new Kubuntu installation.
    >> The reasons I want PHP6 is 1) Late static binding (I so much want to
    >> replicate what I've grown to love in Ruby on Rails) and 2) Real
    >> unicode support (this should've been here soooo long ago

    >
    > Eh, it also has namespaces, as well (though 5.3 has those, too). I've
    > developed PHP for a very long time. I am not not enthusiastic about
    > the road that they're heading down with a great deal of the decisions
    > that they are making, and I cannot fathom continuing to use it.
    > They've decided, for example, to include APC in PHP 6 as a core
    > feature. Why? APC isn't what's needed---it's a bandage to cover a
    > problem that has grown along with PHP's support of object-oriented
    > programming: the PHP compiler and the bytecode execution engine need to
    > become two separate pieces of software.
    >


    I agree that PHP has some basic "defects". It really shows that this project
    started out as a simple script, and has taken weird paths along the way to
    get to what and where it is today. Consistency is really an unknown noun in
    PHP Everything from differences in the naming conventions for built-in
    functions to broken chainability (is that a word?) and a slot machine-like
    chance of the return value of functions being available inline to the APC
    thing you speak of.

    That said, I still like PHP. I recently worked on a very big web project in
    Ruby on Rails, which definitely is sweet in many respects, but it also
    sucks in others, specifically every time you want to do "something they
    didn't think of". PHP is the diametrically opposite, and I like the freedom
    it offers me, even if it means I have to put up with a lot of clunkiness,
    weirdnesses and inconsistencies.

    > For example, If one could compile the scripts such that they were
    > on-disk in compiled format, and then mod_php were to load the bytecode
    > and execute _that_ (possibly caching the result itself, since it is
    > rather easy to see when the mtime on the bytecode file changes), life
    > would be a _great_ deal easier. It'd also be more efficient then
    > keeping the scripts on-disk in their source code form, since PHP reads
    > the source and compiles it to bytecode upon every page hit anyway,
    > without APC.
    >
    > There are other bandages that they're applying, and they may work for
    > some people, but I can't see myself using them when such things could
    > be much more easily fixed at the source. Unicode support is great, for
    > example: it should've been supported everywhere a long time ago. It's
    > slower in PHP than plain ASCII support, and that is to be expected,
    > though I expect that some large gains in performance will be necessary
    > in PHP's handling of Unicode throughout its API: I read on one of the
    > PHP developer's blogs (can't recall where ATM) that the Unicode support
    > reduces string-heavy manipulation speeds by about 25%. Most PHP
    > applications perform a *lot* of string manipulation, so this will be a
    > very noticeable performance hit.
    >


    I so much agree. UTF-8 is not a nice-to-have feature, it's a must-have
    feature. Having to manually convert everything back and forth is a real
    hassle. I don't care much about the performance reduction that UTF-8
    support will introduce, the time I spend less doing manual conversions will
    indirectly pay for new server hardware through me having to work less time
    on each project

    >>
    >> Anyways, I'm not giving up quite yet. I'll try to get rid of that
    >> error soon, but rigth now I think I'll relax with a couple of beers
    >> and a movie. I *am* on vacation, hehe
    >>
    >> Oh, btw, if you know of 5.3 deb packages existing anywhere, those'd be
    >> great, too, since they at least satisfy my wish no. 1 about late
    >> static binding
    >>

    >
    > I can't find any in PPAs


    I didn't know that existed! Just found it Cool, thanks :P

    > or the like, and there don't appear to be any
    > at backports.org. However, you should be able to take the PHP 5.2
    > source package from a reasonably modern Ubuntu, and use the uupdate
    > utility to update it to a PHP 5.3 snapshot, with modifications.
    >
    > Essentially, though, I am recommending that if you aren't going to be
    > using the package manager and its utilities to create packages, that
    > you install from source in the usual way for Unix-like systems and
    > install the programs in their own trees as I pointed out above.
    > Speaking from experience, this makes their management *much* easier.
    >
    > HTH,
    > Mike
    >


    Sure did Thanks for all you time

    Daniel

+ Reply to Thread