Johnny Hughes napsal(a):
evolution-2.0.2-35.0.4.el4.i386 evolution-connector-2.0.2-10.rhel4.1.i386 evolution-data-server-1.0.2-14.el4.i386 evolution-webcal-1.0.10-3.i386 gnutls-1.0.20-3.2.3.i386 gnutls-devel-1.0.20-3.2.3.i386 gnutls-devel-1.0.20-3.2.3.i386 libgcrypt-devel-1.2.0-3.i386 libsoup-2.2.1-4.i386 libxslt-1.1.11-1.i386 NetworkManager-0.3.1-4.el4.i386 vino-2.8.1-1.i386 wireshark-0.99.5-EL4.1.i386 wireshark-gnome-0.99.5-EL4.1.i386 yelp-2.6.4-2.i386
So, all of those pacakges would need to be checked and probably most will need to be rebuilt ... not sure it is worth that effort.
Well, not sure, majority of them are GUI, since mod_gnutsl is for servers mainly... We can drop support for "Desktop". Basically you do not need GUI on server, at least I do not want to :o). I'm not sure about libxslt and libsoup, but --whatrequires returns nothing on my production servers. But I might not be authoritative.
WRT apr_memcache, we also need to build memcached (apr_memcache is a client for memcached, not a standalone program). memcached allows for several machines to be used for caching requests. RPMForge seems to have the latest version of memcached ... so I guess I can build that as well (for repo closure).
I would leave memcached as php-pecl-memcached on Dag :o) and create separate package for memcache client only... They have to be separated.
Good, that is a long term enterprise source for an updated gnutls and libgcrypt ... but all the other packages that need rebuilding also need tracking and relabeled (probably version needs %{?dist} added to it ... where %dist is .el4.centos.
Yes, I'm used to have spec files "%{?dist}isized". I use ".el(4|5).hrb". We should stick with C5 version to track patches etc. SRPMS are here http://fs12.vsb.cz/hrb33/el4/hrb/testing/i386/SRPMS/repodata/ David