On Tue, Apr 26, 2005, Etienne-Hugues Fortin wrote: > I don't have much packages modified this way so I don't mind redoing > those correctly. I've read your last paragraph and you're telling me to > basically download all the sources that I need from CVS and to modify > those directly. However, I can't see how this will help me with upgrade. > Are you always using the same CVS tree for a specific application for > each version? Otherwise said, if I have let say Apache 1.3.2 and moving > to Apache 1.3.3 or even 1.4 (hey, it's just an example), is it under the > same CVS tree that I'll be able to update with cvs update -Pd?
Yes, OpenPKG's package versions are all in the same package tree under the same filenames. For instance the openpkg-src/apache/apache.spec file in CVS contains _all_ versions since OpenPKG 1.0, just on different CVS revisions and branches. For instance, if you have openpkg-src/apache/ checked out locally into subdir "apache" with "cvs -d :pserver:[EMAIL PROTECTED]:/v/openpkg/cvs co -d apache openpkg-src/apache" you have the OpenPKG-CURRENT "apache" packaging in front of you. If you want to see how it looked in OpenPKG 2.3-RELEASE, you do a "cd apache; cvs up -rOPENPKG_2_3_RELEASE". If you want to see the latest 2.3.x version of this package you do "cd apache; cvs up -rOPENPKG_2_3_SOLID", etc. See http://www.openpkg.org/cvs.txt for details on the CVS tags we are using. > I also have a related question. Yesterday I compiled and installed the > ipfilter libraries in order to install ip_filter. Now, I want to modify > Squid in order to activate the ipf_transparent feature. I tried doing a > openpkg --rebuild <package_name> --define "option 1" -- define "option > 2". However, this is not working. I'm receiving message saying that the > define macro does not exist. Should it work? Well, if the "option" doesn't exist, it will not work. Run "openpkg rpm -qpi" on the *.src.rpm file to see what built-time options it actually supports. In your case, there is no "ipf_transparent" or similar feature. We would have to add this first. > And what about adding include path? My ipfilter libraries are under > /usr/include/ipfilter and I didn't find any way to tell openpkg to > include this directory (or any directory I should say). I don't want to > copy everything back to /openpkg/include... You can neither tell OpenPKG to include something outside (because that's against the design philosophy of OpenPKG) nor just copy everything to /openpkg/include/ (because that's against the design philosophy of a packaging approach like RPM). If you really need this functionality, you have to (1) create an "ipfilter" package and (2) change the "squid" package to require and built against "ipfilter" under a new "squid" build-time option "with_ipfilter". > These are newbies questions but I can't seems to find answers in the > FAQ or handbook. Oh, well, the basic problem you are confronted with is actually whether a packaging approach allows you to do what you want to do. It should became clear to you now that everything is _possible_ if you are able to package _yourself_ a little bit, but out-of-the-box you have just a limited (although rather large) extend of possibilities. This less flexibility is the price of being able to use all the other nice features of packaging like easy upgrades, queries, etc. For full flexibility (which allows you to perform also esoteric installations) you would have to perform manual installations... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ______________________________________________________________________ The OpenPKG Project www.openpkg.org User Communication List openpkg-users@openpkg.org
