On Viernes 12 Noviembre 2010 21:37:32 Michael Tautschnig escribió: > Hi Noel, > > [...] > > > I'm not interested (at the moment) in how these data are updated or > > maintained, since I want to have a bunch of packages in shape for kstars > > usage in wheezy. After having the packages as intended, I will try to > > put them in consonance with the stardata-common framework ( > > https://alioth.debian.org/scm/browser.php?group_id=30498 ). > > > > After that, I could consider using getData, but the Tycho catalog is sort > > of stable, so I do not think it is appropiate. > > [...] > > 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? I do not want these packages to be my pet packages, and I would very gladly leave them on hands of Debian Qt/KDE Maintainers but I think they're actually a bit overloaded. I would be happy to maintain these packages from inside that team, but I want to have them in shape before that. About how often is kstars installed in true multiuser systems, one system is enough for me to say that there is a problem, but I've been sysadmin at universitary computer rooms, and numbers are quite higher that one. But, To make a long story short: I saw a need, and I'm working towards a solution. It is up to you to be happy with it or not, but it works for me and can work for others. > > 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? 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". It may be that four of the nine packages in sight (two of them are not free, so actual number is two) can happen to be under the scope of stardata-common, the other five are not catalogs at all. I would be happy (again) of working them inside that framework, as I've discussed already with Javier, but it is still to be seen if it is possible. I still have to study the project and the kstars data format in order to decide if it is possible, and both things will require a lot of time. These packages, in turn, solve the problem and don't create new ones, so why not to have them? They will be integrated later, _if possible_. Why not start asking Debian Qt/KDE Maintainers to work with upstream in order to get Gliese and Yale catalogs out of actual kstars-data package? I would do that, but having the proposed packages in Debian in order to solve the actual problem is of higher importance to me than diving into stars.dat, namedstars.dat and unnamedstars.dat from that package to remove the stars tha are actually in the gliese and yale packages. > > 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. Don't sponsor these packages, I hope others will have better sight on the problem I saw (which, by the way, has actually happened to have collateral benefits for the upstream KStars team out of Debian, as they have re-checked the License of their web-distributed Tycho2 and USNO Nomad files). > > Best regards, > Michael Thanks for your comments, I've learned from them. Noel er Envite
Attachment:
signature.asc
Description: This is a digitally signed message part.