[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: kstars-data-extra-tycho2 (third try)

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.

er Envite

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: