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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
