Re: HEADUP for all PEAR packages
Le 24/10/2012 00:04, Adam Williamson a écrit : Would it be super-hard to just write a bot that does PEAR package builds and updates? That seems like it'd mostly solve the problem. Something like: pear make-rpm-spec foo-1.2.3.tgz rpmbuild -ba foo.spec Yes, this is mostly automatic, but remember the packager really do much work (license review, bundled lib, test, QA, ...) And often, the review can take... some time... Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HEADUP for all PEAR packages
On Wed, 2012-10-24 at 09:02 +0200, Remi Collet wrote: Le 24/10/2012 00:04, Adam Williamson a écrit : Would it be super-hard to just write a bot that does PEAR package builds and updates? That seems like it'd mostly solve the problem. Something like: pear make-rpm-spec foo-1.2.3.tgz rpmbuild -ba foo.spec Yes, this is mostly automatic, but remember the packager really do much work (license review, bundled lib, test, QA, ...) And often, the review can take... some time... Well sure, but that only affects initial submission, not update. It seemed the complaint was both that some PEAR modules aren't in Fedora at all, *and* that what is in Fedora is often out-of-date. At least the second problem seems reasonably solve-able. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
HEADUP for all PEAR packages
For years... pear have its metadata database stored in /usr/share/pear
This will move soon to /var/lib/pear (to be FHS compliant).
(feature approved/merged by upstream)
With this last change, we'll have only libraries in /usr/share/pear
(which is part of the default php include_path)
WARNING : all pear packages will be FTBFS.
Very simple fix:
Define the default metadata directory location
%{!?pear_metadir: %global pear_metadir %{pear_phpdir}}
And instead of
# Clean up unnecessary files
rm -rf %{buildroot}%{pear_phpdir}/.??*
Use
rm -rf %{buildroot}%{pear_metadir}/.??*
This can be applied on all branches
(already used on some of my packages, see php-phpunit-PHPUnit p.e.)
Best regards,
Remi.
[1]
http://pkgs.fedoraproject.org/cgit/php-phpunit-PHPUnit.git/commit/?id=a010eeaf57324c5f9cbb8580f14d589dcf7b6f62
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HEADUP for all PEAR packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 23/10/2012 16:44, Reindl Harald a écrit : does pear update pear this also know? Currently we have latest pear 1.9.4 in fedora. As this feature have been merged by upstream, yes next version will be aware of this feature. And pear, in fedora, is mostly released closed to upstream. in the real life mostly even as RPM packed pear packages are updated with pear upgrade because the RPM's are way behind by design I disagree. RPM maintainers keep a consistent PEAR stack and add more QA. Before running any pear update ... you should ask why this is not available as RPM. I have often differ updates because new package is broken (or break others) Remi. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCGud0ACgkQYUppBSnxahgouQCeLE/Mg2QyOhf+qY1mIttQv1qS 6uwAnA6E9E12HUVvzJJQRc2x/S5iK6Vx =6imF -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HEADUP for all PEAR packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 23/10/2012 17:45, Reindl Harald a écrit : because i never found all used packages as RPM And ? What are you waiting for ? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCGvl8ACgkQYUppBSnxahhpRQCg8GJigG2A5l/+nf0Ih+TFVJ9J ZPoAniCMhYubYosU/tUZz+8x/DE8RpyD =EqAl -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HEADUP for all PEAR packages
Am 23.10.2012 16:40, schrieb Remi Collet:
For years... pear have its metadata database stored in /usr/share/pear
This will move soon to /var/lib/pear (to be FHS compliant).
(feature approved/merged by upstream)
With this last change, we'll have only libraries in /usr/share/pear
(which is part of the default php include_path)
WARNING : all pear packages will be FTBFS.
Very simple fix:
Define the default metadata directory location
%{!?pear_metadir: %global pear_metadir %{pear_phpdir}}
And instead of
# Clean up unnecessary files
rm -rf %{buildroot}%{pear_phpdir}/.??*
Use
rm -rf %{buildroot}%{pear_metadir}/.??*
This can be applied on all branches
(already used on some of my packages, see php-phpunit-PHPUnit p.e.)
does pear update pear this also know?
in the real life mostly even as RPM packed pear
packages are updated with pear upgrade because
the RPM's are way behind by design
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HEADUP for all PEAR packages
Am 23.10.2012 17:38, schrieb Remi Collet: in the real life mostly even as RPM packed pear packages are updated with pear upgrade because the RPM's are way behind by design I disagree. RPM maintainers keep a consistent PEAR stack and add more QA. Before running any pear update ... you should ask why this is not available as RPM. I have often differ updates because new package is broken (or break others) because i never found all used packages as RPM i would be much more happy to not have any php-package depend on pear-RPMs my QA is test against the used software with internal unit-tests and rsync /usr/share/pear as it is on all other machines which is one reason more why i do not like a additional split to /usr/share/doc/pear/ while some years ago you had to care only about one folder to distribute pear-updates per RPM are often enough downgrades here Installed packages, channel pear.php.net: = Package Version State Archive_Tar 1.3.10stable Archive_Zip 0.1.2 beta Auth 1.6.4 stable Auth_HTTP2.1.8 stable Auth_SASL1.0.6 stable Benchmark1.2.9 stable Cache1.5.6 stable Cache_Lite 1.7.15stable Config 1.10.12 stable Console_Color1.0.3 stable Console_Getargs 1.3.5 stable Console_Getopt 1.3.1 stable Console_ProgressBar 0.5.2beta beta Console_Table1.1.4 stable Contact_Vcard_Build 1.1.2 stable Contact_Vcard_Parse 1.32.0stable Crypt_Blowfish 1.0.1 stable Crypt_CBC1.0.1 stable Crypt_CHAP 1.5.0 stable Crypt_DiffieHellman 0.2.6 beta Crypt_GPG1.3.2 stable Crypt_HMAC 1.0.1 stable Crypt_RC41.0.3 stable Crypt_RSA1.0.0 stable Crypt_Xtea 1.1.0 stable DB 1.7.14stable Date 1.4.7 stable Date_Holidays0.21.6alpha Date_Holidays_Austria0.1.4 alpha Event_Dispatcher 1.1.0 stable File 1.4.1 stable File_CSV 1.0.0 stable File_CSV_DataSource 1.0.1 stable File_DNS 0.1.0 devel File_Find1.3.1 stable File_IMC 0.5.0 beta File_PDF 0.3.3 beta File_Passwd 1.1.7 stable File_SearchReplace 1.1.4 stable File_Util1.0.0 stable HTML_AJAX0.5.6 beta HTML_BBCodeParser1.2.3 stable HTML_CSS 1.5.4 stable HTML_Common 1.2.5 stable HTML_Common2 2.1.0 stable HTML_Crypt 1.3.4 stable HTML_Entities0.2.2 alpha HTML_Form1.3.0 stable HTML_Javascript 1.1.2 stable HTML_Menu2.1.4 stable HTML_Page2 0.6.3 beta HTML_Progress2 2.4.2 stable HTML_QuickForm2 2.0.0 stable HTML_Select 1.3.1 stable HTML_Table 1.8.3 stable HTML_Table_Matrix1.0.10stable HTML_TagCloud1.0.0 stable HTML_TreeMenu1.2.2 stable HTTP 1.4.1 stable HTTP_Client 1.2.1 stable HTTP_Download1.1.4 stable HTTP_Header 1.2.1 stable HTTP_OAuth 0.2.3 alpha HTTP_Request 1.4.4 stable HTTP_Request22.1.1 stable HTTP_Session20.7.3 beta HTTP_Upload 0.9.1 stable I18Nv2 0.11.4beta Image_Canvas 0.3.5 alpha Image_Color 1.0.4 stable Image_Color2 0.1.5 alpha Image_Graph 0.8.0 alpha Image_GraphViz 1.3.0 stable Image_IPTC 1.0.2 stable Image_JpegMarkerReader 0.5.0 beta Image_JpegXmpReader 0.5.3 beta Image_Puzzle 0.2.2 beta Image_Remote 1.0.2 stable Image_Text 0.6.1 beta Image_Transform 0.9.5 alpha Log 1.12.7stable MDB2 2.5.0b3 beta MDB2_Driver_mysql1.5.0b3 beta MIME_Type1.3.1 stable MP3_IDv2 0.1.8 alpha MP3_Id 1.2.2 stable MP3_Playlist 0.5.2 alpha Mail 1.2.0 stable Mail_Mime1.8.5 stable Mail_mimeDecode 1.5.5 stable Math_BigInteger 1.0.0 stable Math_Stats 0.8.5 stable Message 0.6 beta Net_CheckIP 1.2.2 stable Net_DNS 1.0.7 stable Net_FTP 1.3.7
Re: HEADUP for all PEAR packages
Am 23.10.2012 17:57, schrieb Remi Collet: Le 23/10/2012 17:45, Reindl Harald a écrit : because i never found all used packages as RPM And ? What are you waiting for? what should i wait for? pear install whatever pear itself is a package-system which should not be wrapped in another one - the rpm-db overhead with a lot of files is mostly larger than the scripts itself. only php-pear would be needed to have the pear commands available and all would be fine if there would not be some packages require pear-rpms signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HEADUP for all PEAR packages
On 10/23/2012 06:00 PM, Reindl Harald wrote: Am 23.10.2012 17:57, schrieb Remi Collet: Le 23/10/2012 17:45, Reindl Harald a écrit : because i never found all used packages as RPM And ? What are you waiting for? what should i wait for? pear install whatever pear itself is a package-system which should not be wrapped in another one - the rpm-db overhead with a lot of files is mostly larger than the scripts itself. I couldn't disagree more. Using a centralized packaging system has the benefit to be able to install an exact version on all managed hosts. Show me, how to do that with pear. Is pear also able to answer you: to which package belongs file ? I'd even propose to disable other packaging systems in Fedora, or to change them to prompt the user: Yes, I know this voids warranty and I'll take the risk (or something like that). Pear is here just a example, but there are other package systems in fedora as well: python-pip, I know there's something similar in ruby (gem?),... -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HEADUP for all PEAR packages
Am 23.10.2012 19:03, schrieb Matthias Runge:
On 10/23/2012 06:00 PM, Reindl Harald wrote:
Am 23.10.2012 17:57, schrieb Remi Collet:
Le 23/10/2012 17:45, Reindl Harald a écrit :
because i never found all used packages as RPM
And ?
What are you waiting for?
what should i wait for?
pear install whatever
pear itself is a package-system which should not be wrapped
in another one - the rpm-db overhead with a lot of files
is mostly larger than the scripts itself.
I couldn't disagree more.
Using a centralized packaging system has the benefit to be able to install an
exact version on all managed hosts.
Show me, how to do that with pear
nothing easier than that, proven on 20 production servers
and 5 development machines since 2008 while the machines
were installd with F9 and until now upgraeded with yum
to F17 - so yes i know how to manage hosts
[root@buildserver:~]$ cat /buildserver/distribute-pear.sh
#!/bin/bash
source /Volumes/dune/buildserver/server-list.txt
find /usr/share/pear/ -type d -exec /bin/chmod 0755 {} \;
find /usr/share/pear/ -type f -exec /bin/chmod 0644 {} \;
find /usr/share/doc/pear/ -type d -exec /bin/chmod 0755 {} \;
find /usr/share/doc/pear/ -type f -exec /bin/chmod 0644 {} \;
function rh_push_pear
{
echo $1
rsync --times \
--progress \
--force \
--recursive \
--delete-after \
--links --perms \
--owner --group \
--executability \
--acls \
--xattrs /usr/share/pear/ root@$1:/usr/share/pear/
echo
}
for item in ${RH_TARGET_SERVERS[*]}
do
rh_push_pear $item
done
Is pear also able to answer you: to which package belongs file ?
no, but that does not change the problem of having hundrets of
pear apckages and only a subset as RPM - so in the real world
you mix them which is BAD
if ALL pear packages would be in the repos this whould be
a diffeent story - but taht is unlikely because who
would maintain all this packages really?
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HEADUP for all PEAR packages
On 10/23/2012 08:40 AM, Remi Collet wrote:
For years... pear have its metadata database stored in /usr/share/pear
This will move soon to /var/lib/pear (to be FHS compliant).
(feature approved/merged by upstream)
With this last change, we'll have only libraries in /usr/share/pear
(which is part of the default php include_path)
WARNING : all pear packages will be FTBFS.
Very simple fix:
Define the default metadata directory location
%{!?pear_metadir: %global pear_metadir %{pear_phpdir}}
And instead of
# Clean up unnecessary files
rm -rf %{buildroot}%{pear_phpdir}/.??*
Use
rm -rf %{buildroot}%{pear_metadir}/.??*
This can be applied on all branches
(already used on some of my packages, see php-phpunit-PHPUnit p.e.)
I presume php-pecl packages are un-affected by this?
--
Nathanael d. Noblet
t 403.875.4613
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HEADUP for all PEAR packages
On Tue, 2012-10-23 at 21:42 +0200, Reindl Harald wrote: if ALL pear packages would be in the repos this whould be a diffeent story - but taht is unlikely because who would maintain all this packages really? It seems like something that should be automatable, really. Don't we already have this, to some degree? The layout, contents and build process for PEAR packages is standardized, AIUI, so they can use virtually the same spec file and bumps should be entirely automatable in the vast majority of cases. Would it be super-hard to just write a bot that does PEAR package builds and updates? That seems like it'd mostly solve the problem. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HEADUP for all PEAR packages
On Wednesday, October 24, 2012 06:04 AM, Adam Williamson wrote: On Tue, 2012-10-23 at 21:42 +0200, Reindl Harald wrote: if ALL pear packages would be in the repos this whould be a diffeent story - but taht is unlikely because who would maintain all this packages really? It seems like something that should be automatable, really. Don't we already have this, to some degree? The layout, contents and build process for PEAR packages is standardized, AIUI, so they can use virtually the same spec file and bumps should be entirely automatable in the vast majority of cases. Would it be super-hard to just write a bot that does PEAR package builds and updates? That seems like it'd mostly solve the problem. You'd still have to review the license of the sources before actually pushing the package. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HEADUP for all PEAR packages
Le 23/10/2012 23:02, Nathanael D. Noblet a écrit : I presume php-pecl packages are un-affected by this? Right. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
