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.ascDescription: This is a digitally signed message part.