Creating separate trees may not be the best way to go, although separating the directories is fine. I'd put the Debian, RedHat and SUSE stuff under the openca-0.9 directory, in a directory called "packaging", perhaps as so:
openca-0.9
packaging
READMEs, packaging makefiles and packaging docs...
debian...debian stuff, including package definitions
redhat
..spec files
suse
...suse specific packaging info
Keeping it in the same tree and not branching is very important and very valuable, for several reasons.
First, it's important that packaging work well for both Debian and RedHat style packages. I know that for my application, packaging is important in general, since it makes OpenCA *much* easier to deploy. Whether I use a ".rpm" or a ".deb" has to do with the platform used for the particular project. But almost always, deploying with a package is better than customizing OpenCA by hand for every deployment.
Second, I don't think that the needs of Debian packagers and RedHat packagers differ very much. Either packaging system probably can (and probably should) factor the code into the same modules. They will also need to tweak many (or most) of the same parameters.
Third, if we want to keep packages building correctly as the project changes, it's important to test rebuilding frequently. This is best done if the package definitions are in the regular tree, since in general the package maintainers will want to pick up bug fixes quickly. Responsibility for testing if a package build is broken should stay with the folks who care about that kind of package (folks like me or the people working on the .deb), rather than the central OpenCA project people like yourself. But it's important that we know when package builds break as soon as possible, so that they don't get so badly out of sync again.
I'm happy to keep working on the RPM .spec files. But if my changes are in a separate branch, I'd need to keep merging changes from the regular tree as well. This is much more work both for me and for the Debian people.
Why don't we start a simple design document describing the needs of packagers, and documenting things like:
* How to break the OpenCA source into packages
* Standards for deployment (so that Debian and RedHat packages are
as similar as possible, but still right for each platform).
* What variables should be used in Makefiles and in autoconf to make
creating packages as easy as possible.This documentation will make sure that everything the Debian folk and the RedHat folks learn about packaging will available to current and future developers, and will make it easier for other people who create and fix Makefiles to be compatible with the needs of packagers.
How does this sound to you?
I'm CC'ing Alessandro as well, since it makes sense for me to use his work on the .deb files in any fix I make on the .rpm specs.
Regards, Rob
Michael Bell wrote:
Hi Rob,
some time ago I build RPM packages for 0.9.1. I stop it because the packages are not usable. The result were big changes for 0.9.2 to allow maintainers to build usable packages. I never tried to build RPM packages for 0.9.2.
During the time there was a more strategic change. If it is possible then we want to seperate the package stuff from the core sourcecode. Today the specs are into the source code of OpenCA :(
I would like to create seperate CVS trees for every distribution. This is more easier to handle and an RPM fix cannot crash Debian builds if it is only a RedHat specific problem. My idea is to move the complete RedHat and suse stuff to seperate directories. Example
CVS Root ======== openca-0.9 debian Debian stuff redhat /modules *.spec /interface *.spec Makefile suse /modules /interfaces Makefile
This architecture would allow independent tagging for OpenCA and different RedHat, Debian etc. releases. We have also the advantage that packagemaintainers can work with a centralized CVS system. Of course we would have to do some work to extract the package code from OpenCA but it is an investment for the future and reduce the sources of errors in our make system.
Rob Thorne wrote:
* Some of the .spec files are writing files to system directories on
the build systems, which can't be right. For example, some of the
perl module RPM specs are writing to perl system directories
during rpmbuild -ba.
* Many of the spec files don't use the BuildRoot directive or the
RPM_BUILD_ROOT variable, causing the %install directives to do
funny things like write to system directories during package builds.
* Many of the "install" targets want to set group and owner even
when called for package builds. This isn't that bad, although it
does require the package builds to run as "root". Since the
scripts are otherwise also misbehaving, though, this makes running
the scripts as root a little risky :-(
It was the first time I ever build RPM packages. Install targets must include user and group permissions to establish a minimum security. How do you want to create the default permissions in the packages without the install options?
General info: I'm building on RedHat 9 using
make -f Makefile.devel rpms
This is what I want to move to redhat/. Would it be a good idea to put the stuff directly into our CVS?
Michael
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ OpenCA-Devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/openca-devel
