You are not logged in.
Hello,
Let me say first of all, I'm relatively new to the archlinux dist. That being said I've folllowed the instructions for making a abs PKGBUILD file for the latest STABLE release of openldap. I have a few questions though if I may?
1. Open ldap uses a somewhat strange versioning system .. the file is openldap-stable-<DATE>.tgz but it extracts to a openldap-2.4.16 directory.. I've worked around this by creating a new var pgkverM and giving it the date of the build (20090411). Per the abs package guidelines is this something that is allowed? If not how might I achieve this and stay withing.
2. Baring a fix or approval of #1, is this something I can/should share with the rest of the community? If so, whats the process for submission/approval ? I'd love nothing more than to contribute my part to the community...
The package is a very simple build all in all.. I looked at the pkgbuild from the abs repo's for the old version. which by the way is an outdated RELEASE (not stable) version. I found a workaround for solving the cpeerid error without having to patch any of the source..
Thanks
Offline
1. If you really have to introduce variables in a PKGBUILD, their name should begin with an underscore (_).
2. Do not send your PKGBUILD to the AUR, send it to the maintainer of the package instead or put it in here.
Thank you for contributing!
Offline
Just so you know, this actually is not quite as simple as updating one package. There is a soname bump on libldap that requires rebuilding:
[core]
nfsidmap-0.21-2
[extra]
alpine-2.00-3
apache-2.2.11-3
apr-util-1.3.4-1
autofs-5.0.4-4
claws-mail-3.7.1-1
courier-authlib-0.62.2-2
courier-mta-0.61.1-1
cyrus-sasl-2.1.22-10
cyrus-sasl-plugins-2.1.22-10
dirmngr-1.0.2-1
dovecot-1.1.15-1
ekiga-3.2.4-1
evolution-2.26.2-1
evolution-data-server-2.26.2-1
evolution-exchange-2.26.2-1
gconf-2.26.2-1
gnash-common-0.8.5-2
gnash-gtk-0.8.5-2
gnupg-1.4.9-1
gnupg2-2.0.11-1
kdepimlibs-4.2.3-2
kdevelop-3.5.4-1
kopete-cryptography-1.3.0-2
lighttpd-1.4.22-3
mod_perl-2.0.4-3
nss_ldap-264-1
pam_ldap-184-1
pdns-2.9.22-2
php-5.2.9-3
postfix-2.5.6-2
samba-3.3.4-1
seahorse-2.26.2-1
smbclient-3.3.4-1
subversion-1.6.2-2
sylpheed-2.6.0-1
wine-1.1.21-1
[community]
balsa-2.3.28-1
cherokee-0.99.15-1
dbmail-2.2.11-2
freeradius-2.1.4-1
gq-1.2.3-1
hula-r2661-1
kdesvn-1.3.0-2
libgda3-3.1.5-2
mailutils-2.0-5
opensips-1.5.0-2
pppd-ldap-0.12b-1
pppd-ldap-simple-0.12b-1
python-ldap-2.3.6-1
qsvn-0.8.1-1
rapidsvn-0.9.8-1
Offline
Most users should use "release" (general use) versions.
And if you do that, you don't need to mess around with custom variables.
IMO Arch should use the "release" version because it is the latest upstream version. The openldap devs have applied additional parameters to their use of the word "stable" i.e. they say its stable only when it has
demonstrated itself as being reliable in real world environments.
Arch does not wait for demonstrations of real-world reliability for any other application, so I don't think it should for openldap either.
http://www.openldap.org/faq/data/cache/226.html
http://www.openldap.org/faq/data/cache/225.html
Offline
Well the difference in waiting (using stable) could mean someone having discovered security vulnerability. Major security issue in my opinion especially with ldap. In any case I wasn't posting to debate which version to use. Thats a whole other issue, probably best debated somewhere else. However, the client/server versions in the repo's right now are a whole major version number behind (2.3..43-1) but from the feedback I got here simply replacing it in the repo is not as simple as I thought it was.
I realize most users don't release 'core' packages. I basically just wanted to know if what I had done could somehow contribute to the community or towards making Arch better. From the feedback I have it looks like a 'keep it to yourself' type of thing.
Anyhow thanks for the feedback, I've learned my lesson...
Offline
You can still send your PKGBUILD to the maintainer and/or post it here, as long as you are aware that it will not be acted on until the maintainer and the other devs have the time to complete the substantial list of dependant rebuilds posted by Allan.
I posted my €0.02 about release vs. stable versions because using the release version simplifies your PKGBUILD and makes your original question 1 unnecessary.
Offline
Yes, Absolutely. using the release version does simplify the PKGBUILD into the more standardized format.
I've realized also that the ldap package is split into 3 parts.. lib client and server..I've got it building as a whole. no clue how I'd split them like the core repo's do..
Last edited by davidmirv (2009-07-20 20:52:00)
Offline
I had posted a message a few days before this post regarding the old version of openldap Arch is using, and I appreciate you trying to work on it. But yeah, apparently there are many packages that need to be updated for it to work correctly, though hopefully this will be done soon, before the stable version becomes outdated once again
Offline
I hear rumors that this has been waiting for KDE-4.3 to move into the repos because overlapping big rebuilds are really annoying...
Offline
I understand, just fyi Arch is behind almost every other distro on this one lol
Offline
Anybody has any news on this? KDE 4.3 has already hit the repos, and libldap is still unupdated...
Offline
It overlaps with the ruby rebuild in [testing] which is waiting on the vi/vim/gvim packages to move.
Offline