Hi again, I think sounded pretty rude in my earlier mail; I'm sorry, I didn't mean to be rude. I just had got the impression that you were waving away other people's suggestions for no reason obvious to me. [...] > > > > Would you mind to elaborate in what respect this is going to be more than > > your little pet package? Is kstars that often installed on true multi-user > > systems such that a quick hack is warranted? > > I do not want a quick hack but a truly good package that allows users to have > their systems fully installed through Debian packaging systems. I do not know > why one needs to download data from the network for a program that is > packaged: kstars data is not a non-distributable PDF reader to need an > installer outside the packaging system. Is it? > You're right; I just hadn't fully accepted that is was a simple data package that will ensure the data doesn't get stored for each and every user, but just once and for all on the system. [...] > > > > I find it very unfortunate that you refuse to integrate with existing > > Debian work right from the start. Given that your package is unlikely to > > make it into Squeeze anyway, IMHO there is no need to hurry. Why not > > prepare a nicely integrated package right away, what would you expect to > > gain from this first shot if you'll later plan to transition to > > stardata-common anyway? > > I agree that there is no hurry, but I'm working on the set to have it in shape > for wheezy. Would you prefer for me to wait? > Oh no, surely not, I was rather hoping that ... > About the transition to stardata-common, the problem with that is that I'm > still not convinced that it is compatible with this package set. The source > for this version of the Tycho2 package is not the original data as-is but a > subset of it, but even the stardata-common concept may be not applicable to > other packages of the set like ephemerides, DST rules, images or icons, as > stardata-common is "Common framework for handling stardata catalogues in > Debian" and not anything similar to "Common framework for handling > astronomical and related data in Debian". > [...] (more detailed explanation of your point) ... you could go for stardata-common right now. This might be a bit more work (and you would hence possibly miss the Squeeze freeze), but I still believe in it being beneficial. It would actually even more reduce the disk space and band width usage if several packages shared such data. I understand that this is non-trivial. So why was I panicking? Once the package has entered the archive, it will stay. It does what you wanted it to do, and it will be hard to enforce any changes. Here and now is my only chance to try to convince you to follow a different route. Of course, bugs could be filed, but none of them would be of release-critical severity. > > Please don't feel offended in any way, but I'm not going to sponsor such a > > package. Of course many others might have a very different attitude and > > will take it, so just don't count on me. > > I'm not offended: I try to learn from everybody's comments, either > constructive or not, but it seems to me (personal humble opinion) that you > missed the point of these packages. I think that a good enough solution is > better than an asimptotycally unreachable perfect one, moreover if it is later > improvable, and even if the perfect solution is actually reachable but in a > long term. > [...] I think I got the point of your packages and while I might still not be the one sponsoring them, it would be for technical reasons only (my knowledge of KDE stuff is really limited). Which may not make a difference for you, but at least for me it was important to have my attitude adjusted. I still hope that there is a convergence towards a common data set for packages interested in the same data, but it shall not block an initial upload. Best regards, Michael
Attachment:
pgpZw6j0s7bq4.pgp
Description: PGP signature