Re: removal suggestion: stars
aba@not.so.argh.org wrote:
> > How about http://release.debian.org/sarge_rc_policy.txt ?
> > Is this outdated? Serious question - I might not have noticed
> > a change here. Please help me out if I'm wrong.
>
> | Documentation in main and contrib must be freely distributable,
> | and wherever possible should be under a DFSG-free license. This
> | will likely become a requirement post-sarge.
>
> (And please don't argue that the star catalogue is not documentation -
> it's definitly not program, the other thing listed on that page.)
I might be tempted to argue, as the other thing isn't 'program' but
'software' which is what database could be. But you are quoting the
wrong paragraph anyway: The stars problem is not with whatever _is_
available in main or contrib, but what it _depends_on_.
That is covered in paragraph 2.:
Packages in main cannot require any software outside of main
for execution or compilation.
> > I be honest I don't know what the current tendency is here and googleing
> > didn't help me. Is there a chance for DFSG free data files to be packaged
> > really soon?
>
> Yes. First, there were some programs which included non-free star
> catalogues. Then, it was decided to split the catalogues off to seperate
> issues - and IIRC there are free ones, and non-free ones. So, the
> catalogues are now removed from stars. The next step should however be
> to package them appropriate in main or non-free.
The data removal was done three months ago. If there are free catalogues
available, why aren't they packaged yet?
> > In my eyes one purpose of the bug tracking system and it's RC severity
> > is to automate the task of considering the packages for release.
> > If the bug is closed by an upload of a working release of stars
> > with dependencies satisfied in main - fine.
> > Otherwise what's the purpose of having stars in sarge, when we agree
> > it's not acceptable to release the present state of it?
>
> I think the way to go would be to get some information from the
> maintainer what his solving strategy would be. If he has a doable one,
> we might wait a bit of time for that. If not, the decision about this
> package could still happen.
That isn't an answer to my above question.
I am also confident that the maintain will solve this issue in the near
future, but I still fail to see a reason to keep the broken, policy
violating version in sarge. It's no shame to have the package remove from
sarge temporarily, nor would that impede further improvements to the package.
Tobias
Reply to: