Martin, Thanks for the quick reply 8-)
How does that affect upgrades, i.e. between versions, does rpm and/or openpkg-tool recognize the concept of "newer" if the version/release is not a number? (Sorry ... that's something I haven't read up on ... it's probably in the RPM HOWTO) I was hoping for some scheme that retains the default openpkg release plus some identifier, making it easier to discern from 'rpm -qa' what packages were customized, and what the corresponding default release/version was that each one was derived from. -- Vinod On Tue, 18 Feb 2003, Andrews, Martin wrote: > Vinod, > > Don't have experience with your other questions but I have been creating > modified RPM's. I have been replacing the release with my own version that > has a prefix for my organization and then an incrementing version number - > starting as "lion.1" in this case. I don't think the release I based it on > needs to be preserved in those fields (but maybe it should be put it in the > description?). Instead my current plan is to add a patch file for the *.spec > file that shows all my changes. This patch won't be used (as it needs to be > down before rpm is run) but will be listed in the sources so that it is > included in my own source rpm for documentation (and possible reuse when > merging with a new release). > > Martin > > > 2. Customized rpm naming > > > > What's a good scheme to name a customized version of a > > src.rpm/binary rpm > > ? For example, if I change the default build options in the > > spec file for > > apache, and create a new apache*src.rpm, I would like to > > distinguish it > > from the original src.rpm/binary rpm before and after > > installation. How do > > people on this mailing list handle this? > > > > Thanks, > > -- > > Vinod ______________________________________________________________________ The OpenPKG Project www.openpkg.org User Communication List [EMAIL PROTECTED]
