>>> Index: Makefile >>> =================================================================== >>> RCS file: /cvs/ports/misc/rpm/Makefile,v >>> retrieving revision 1.24 >>> diff -u -p -u -p -r1.24 Makefile >>> --- Makefile 17 Apr 2011 18:23:19 -0000 1.24 >>> +++ Makefile 3 Jul 2011 00:24:01 -0000 >>> @@ -1,44 +1,78 @@ >>> # $OpenBSD: Makefile,v 1.24 2011/04/17 18:23:19 jasper Exp $ >>> >>> -COMMENT = redhat package manager >>> +COMMENT = linux package manager >>> >>> -DISTNAME = rpm-3.0.6 >>> -REVISION = 5 >>> -SHARED_LIBS = rpm 0.1 \ >>> - rpmbuild 0.0 >>> +DISTNAME = rpm-4.9.0 >>> +EXTRACT_SUFX = .tar.bz2 >>> CATEGORIES = misc archivers emulators >>> >>> +SHARED_LIBS = rpm 0.0 # 0.0 \ >> >> Here, the version can't go backwards, and you go from 0.1 to 0.0. > > Maybe you can help me understand the SHARED_LIBS variable better. When I do > 'make plist', it tells me (among other things) to place these lines in the > Makefile: > > SHARED_LIBS += rpm 0.0 # 2.0 > SHARED_LIBS += rpmbuild 0.0 # 2.0 > SHARED_LIBS += rpmio 0.0 # 2.0 > SHARED_LIBS += rpmsign 0.0 # 0.0 > > So if the first version field cannot go backwards, should I take it to 0.2 > since the current port states 0.1? Why did make plist report 0.0 to me?
The port/package will get upgraded, so I don't think it should be a problem there as there is a version bump, and the files would get removed during upgrade. But I think in general, if for some reason there is two librpm.so.0.1 and librpm.so.0.2 (I don't exactly know what the .so name, I am just guessing) in /usr/local/lib, then to force the use of most recent .so, it is always better to increment. Somebody will correct me if this explanation is wrong.
