Gideon package for Debian (CVS 2002-10-09)

[Stefan Schimanski]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

> So basicly I used the earlier CVS version and modified that one.
> Then you upgraded, and we have two different versions.
> Yes, meantime I reviewed the files in CVS and compared to mine.
> BTW, have you tried the current CVS version out, is it working for
> you? It takes a lot of time to rebuild and test the settings, so I
> haven't tried the current CVS version yet...

I did a build a few days ago. It might be the case that the current 
version doesn't build anymore. Gideon is a moving target, changes to 
the packaging files are normal.

> Some difference, I have found:
> - Gideon or kdevelop package names (I could change mine to Kdevelop
> back, since it is now getting stable)

I prefer the Gideon name as long as it is not released as stable. But 
that's not so important, a simple replace command in the editor of 
you choice....But currently there are people who use kdevelop 2.x, 
but who want to take a look at gideon.

> Debiandirs:
> - --enable-debug / --disable-debug mode  (which should be
> preferred?) - --disable-rpath (?)

They are auto generated by the admin/debianrules file. The admin dir 
is common to all modules in kde cvs, so there is no distinction 
between kdevelop and other packages. For those cases you can and 
should pass the special arguments directly to the configure command 
in the rules file. Things like debugging can be enabled with 
environment variables btw., take a look at admin/debianrules.

> - configkdepim probably not necessary in the CVS-version

It's autogenerated and doesn't harm (look above).

> Control:
> - package names (e.g. some experimental packages have names kdelibs
> instead of kdelibs4) -> kdelibs | kdelibs4 is more general IMHO...

No, those experimental packages are experimental by definition. There 
is no need to do the distinction in every module. if there are 
kdelibs and kdelibs4 out there for the same purpose it's their duty 
to provide proper "Replace" und "Provides" properties in their 
control files.

> - libqt vs. libqt-mt -> both should be supported the same way ->
> libqt3-dev | libqt3-mt-dev

KDE3 uses libqt3-mt by default, doesn't it?! Anything else shouldn't 
appear anyway. If you want to build your package with other settings 
you are free to do so with modified control files IMO. Moreover it's 
not good to use more than one build-depend configuration as the build 
environment will probably produce different binaries. Building should 
be a predictable and determined process normally.

> - kprof could be suggested as well

This probably would make sense. There might be some more reasonable 
suggestions which should be added IMO, docs for kdelibs and qt for 
example.

Greetings
 Schimmi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE9qHkDHUDhE+YrLEURAi4DAJ4gDUB8tijU2r685mK16cP4Lr4URgCdG2Bf
jlQedeDnBywzxQ/zaneeQQo=
=nYbQ
-----END PGP SIGNATURE-----


-
to unsubscribe from this list send an email to kdevelop-request at kdevelop.org with the following body:
unsubscribe »your-email-address«