[Kolab-devel] Packaging

[Steffen Hansen]

On Wednesday 12 May 2004 21:37, Stuart Bingë wrote:
> On Wednesday, 12 May 2004 21:27, Stuart Bingë wrote:
> > On Wednesday, 12 May 2004 21:22, Bernhard Reiter wrote:
> > > It should be possible to create RPMs for testing
> > > and if we want to be really quick after a fix
> > > so for some situations we should keep the possibility.
> >
> > Although isn't what you describe the job of OpenPKG?
> >
> > As far as I understand it, we should just create a new release
> > tarball when we need to update, and let OpenPKG create the SRPM
> > (which we can then grab from OpenPKG-current).
>
> Apologies for the double post.
>
> My above comment was for official releases - I guess it would be
> beneficial to have this functionality for testing though. We can
> easily add the functionality in.
>
> However, I definitely think we should ensure that no RPMs we create
> through this mechanism be used *in any way* as official releases.
> This is exactly the confusion that we've been experiencing in the
> past, which has ended up in version hell.
>
> In other words, the RPMs created through this devtool mechanism
> should never end up on official distribution sites - we should flag
> them as such so that anyone who uses one knows that it is a
> development RPM, and that it has *absolutely nothing* to do with an
> official release.

I don't care. I want to control the spec-file so I can fix it when new 
files are added or whatever, I want to be able to make an rpm whenever 
I like it and make it available to testers.

I initially said that I would not mind a change in CVS structure given 
that

1) My changes are not lost
2) Everything that is possible with the Makefiles is still possible and 
documented.

As it is right now, both 1 and 2 are violated, and I have been paralyzed 
since the CVS restructuring because I am not able to produce a working 
system for even basic smoke-testing and development:

cheyenne:/home/steffen/kolab/cvs/releng/kolab # ./devtool copydevel
+++ copying development sources
cheyenne:/home/steffen/kolab/cvs/devel/kolab # ./kolabd
[kolabd] Kolab is starting up
Use of uninitialized value in exists at Kolab/LDAP/Backend.pm line 66.
Use of uninitialized value in concatenation (.) or string at 
Kolab/LDAP/Backend.pm line 68.
Use of uninitialized value in concatenation (.) or string at 
Kolab/LDAP/Backend.pm line 70.
Use of uninitialized value in concatenation (.) or string at 
Kolab/LDAP/Backend.pm line 71.
[B ERROR] Backend `' does not exist, exiting
cheyenne:/home/steffen/kolab/cvs/devel/kolab # ./kolab_bootstrap -b

KOLAB BOOTSTRAP

Please enter Hostname [cheyenne.hrhansen.dk]:
proceeding with Hostname cheyenne.hrhansen.dk
Please enter your Maildomain [hrhansen.dk]:cheyenne.hrhansen.dk
proceeding with Maildomain cheyenne.hrhansen.dk
could not write to /kolab/etc/sasl/apps/smtpd.conf at ./kolab_bootstrap 
line 124, <STDIN> line 2.
cheyenne:/home/steffen/kolab/cvs/devel/kolab #

This has to change now or I am forced to stay in the server CVS module 
and just continue Kolab development in there.

regards
-- 
Steffen Hansen          |       Klarälvdalens Datakonsult AB
Senior Software Engineer|       http://www.klaralvdalens-datakonsult.se
                        |
                        |       Platform-independent
                        |       software solutions