Tue Jun 7 23:02:43 CEST 2011
"packaging" burden if monolithic tarballs are available. For what it's =
as kdesrc-build author trying to maintain a sample configuration, I agr=
completely, and I make it a business to keep dependency handling as sim=
possible! Actually having to key in dependency data as the packagers wo=
have to do is more work and while the consensus from most packagers see=
be that they were doing that work /anyways/ (and therefore split tarbal=
fine), that's not the case for all of them.
A separate objection had come about from the process of creating split=20=
tarballs (e.g. kdeedu migration as annma already mentioned), not the id=
having split tarballs itself. I think most of us would agree that a smo=
migration to split tarballs is the much preferred mode of operation if =
going to be migrating at all, so I don't see that as controversial eith=
So in other words: Split tarballs are still the answer, but taking a li=
bit of extra work on our end to get a decent monolithic compilation can=
some of packagers save a significant amount of maintenance burden, and =
transition over we just need to take advantage of past experience to tr=
ensure everything moves as smoothly as possible.
- Michael Pyne
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the release-team