I apologize for being so late. I prefer to keep the debian stuff in an unrelated module, since it comprises a lot of files which can have a different history (and tagging/branching) than the mainstream. What will happen as the new stable version will issue, I will ask to May to commit the deb packages to the sid distribution archive. So people will normally only use the packages (or the sources present on the debian mirros), and wuold never use the openca cvs.
On Thu, Jan 29, 2004 at 09:34:06 +0100, Michael Bell <[EMAIL PROTECTED]> wrote: > Rob Thorne wrote: > > >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 > > The problem is that we have to distribute all packaging informations in > every source release and this wastes a lot of space. Now it is only > redhat, suse and debian but there are many other distros. > > >Keeping it in the same tree and not branching is very important and very > >valuable, for several reasons. > > Ok, let's see. > > >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. > > I don't understand this completely. The stuff in debian is really > specific for Debian. If there is a problem with the Makefiles or > something else then we change it directly in OpenCA. We solve such > problems in the same way like your fixes for Makefile.devel. We simply > merge it into the normal source code. Only distribution specific patches > like the absolute symlink problem in Debian will be part of the > distribution directory. > > >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. > > This is correct but no reason why the distribution specific stuff cannot > be in a seperate tree. > > >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. > > Sorry, but this is only a question of comfort. It is no problem to do > this with a seperate tree. > > In fact there is a much bigger problem with the distribution specific > trees - the tagging. If we (OpenCA) release a version then we tag our > distribution but package maintainers have to create for example for > debian up to three (!!!) seperate branches - stable, testing and > unstable (openca_0_9_2_woody branch, openca_0_9_2_0_woody release and > same for sid and sarge). If we use stable for example then we cannot > rebuild with Makefile.devel actually. If we do this in a seperate tree > then we have a good seperation from the OpenCA branches. RedHat and SuSE > are much more difficult because of their fast release cycles. > > If you have as package maintainer access to the CVS then I see no reason > why the stuff must be in openca-0.9/packaging and cannot be in redhat/. > It works for debian so why not for redhat. If all distros requires a > change then we will perform it in OpenCA directly. > > >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. > > ... and this is what I don't understand. Perhaps some definitions: > > tree: a simple directory in the CVS like openca-0.9/ or debian/ > > branch: is a spin-of from a source tree like openca_0_9_1 > > If we (OpenCA) create a new branch e.g. openca_0_9_2 then you can create > such a branch for redhat too but you can create a branch > openca_0_9_2_redhat_9 too. I know that this is perhaps some confusing > but I want to give the package maintainers all the freedom they need > without flooding the openca sourcecode tree. > > >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? > > This is a perfect idea. We could place this document directly in our > technical documentation. docs/guide/tech/packaging.xml > > Is the place ok? > > >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. > > First Alessandro reads openca-devel too. Second do you have a > SourceForge account for the time after the problems with the directory > organization are solved? > > Michael > -- > ------------------------------------------------------------------- > Michael Bell Email: [EMAIL PROTECTED] > ZE Computer- und Medienservice Tel.: +49 (0)30-2093 2482 > (Computing Centre) Fax: +49 (0)30-2093 2704 > Humboldt-University of Berlin > Unter den Linden 6 > 10099 Berlin Email (private): [EMAIL PROTECTED] > Germany http://www.openca.org > > > > ------------------------------------------------------- > 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 ------------------------------------------------------- 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
