Office/ and Utilities/ menu reorganization
thiago at kde.org
Tue Aug 9 02:31:07 BST 2005
Michael Nottebrock wrote:
>I don't buy any of that. Qt and Kdelibs are binary compatible over long
>periods of time, making a tarball is a matter of five minutes maximum
I'm sorry, but have you tried?
I tried making a release for Kopete after the MSN server change. I was
faced with two choices:
1) download the existing tarballs, apply a patch and tar up again
2) try to make the tarballs from SVN
I chose the latter. Maybe it wasn't the best choice, because it took me
several hours to:
- download the sources from Subversion
- download all translations for kopete
- download all documentation for kopete (granted, there are not many)
- package up
- then do a test compile to make sure everything was in order
The test compile alone takes over half an hour.
Half-way through, I gave up getting the translations and doc for the 0.9.x
release (the one in KDE/3.3/kdenetwork). And even with all the care that
I took, the packages were broken and Matt had to create new packages with
a new release number.
It most likely is a lot easier for a small app in extragear. But you are
asking to split a couple of rather large applications from the codebase,
for developers who have never made a single release. Not to mention that
configure tests are spread over the whole module, so the configure.in.in
scripts would have to be adapted.
Another point is that some small apps make no sense being packaged
separately. Users would never find out they exist.
>... and it would mean that users only get kile, kdvi, kghostview and
> kpdf in the end - but not a bunch of very much TeX-unrelated,
> gratuitous stuff like kpovmodeller, kfax, kruler, kview, the X11 gamma
> correction kcm module ...
You miss the point. Instead of tracking one dependency, the user and the
packager now have to track three or more. Add the complexity of versions:
kile 2.0 requires kpdf 1.0, kghostview 0.25 and kdvi 1.5
kile 2.0.1 requires kpdf 1.0.1 to fix a regression
kile 2.1 requires kpdf 1.0.1, kghostview 0.27 and kdvi 1.6
Having said that...
... I do agree we need a reorganisation. But, most importantly, we need a
build system that allows for easy splitting, while at the same time
letting developers build in one go. I'm hoping our next build system has
that feature. Not to mention that the generated configure scripts are
disproportionately large and would increase the amount of data
I also agree some apps could be separated from the main KDE releases.
Applications in kdetoys, for instance, see so little modification that
releasing a new version of kdetoys just because one of them got an
improvement is an overkill.
So, maybe we set message & feature freezes for all apps, but still release
separate tarballs. Translators, documentation writers and packagers
wouldn't have to keep track of 150 applications.
Please note that kdelibs would grow by a substantial amount.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
3. Ac seo woruld wearð geborod, swá se Scieppend cwæð "Gewurde Unix" and
wundor fremede and him "Unix" genemned, þæt is se rihtendgesamnung.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel