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

Re: RFS: assaultcube-data (updated package)



Hi again,

[...]
> >Thanks a lot for updating this package. Yet the new non-repacking leaves some
> >doubts to me:
> >
> >- "Don't repack anymore." is a nice hint that something has changed, but yet it
> >   left me to find this out myself via the debdiff.
> >- Using "repacknot1" as version appears to be a cruel hack. Ideally we'd have a
> >   new upstream version that could be packaged, but if that doesn't happen
> >   soonish, we'll have to live with that hack. (Introducing an epoch doesn't seem
> >   like a better solution either...)
> >- Why do server binaries belong to a "data" package? Isn't that just a hack to
> >   avoid a new source package?
> >- The original license appears to disallow re-packaging/splitting, hence there
> >   must be some exclusive exception provided to Debian. This is, however, not
> >   detailed in the copyright file.
> >
> >Best regards,
> >Michael
> >
> 
> Hello.
> 
> - True, I've changed it to read "Upstream tarball no longer
> repacked; binaries not removed since used", would this be reasonably
> verbose?
> 

Ok, cool, that sounds more helpful.

> - Yeah, 1.1.0.5 is in the works, but when is very uncertain (maybe
> this year...).
> I discussed the renaming on IRC (mentors/games) and it seemed like
> this was the most reasonable solution.
> 

Ok, thanks a lot for the info.

> - Would splitting it into two source packages be better, it seems a
> tad unnecessary?
> Upstream distributes one "AC" package with precompiled binaries and
> data for "compile-less" usage (which Debian uses only for data
> currently), and an AC-source package, which Debian uses to create
> the packages with the binaries.
> Since the binaries comes in the upstream tarball which Debian calls
> "-data" I guessed it would be best to use this source package
> as-is..
> 

In this case I do agree that splitting is probably too much of a hassle.
However, the name still doesn't seem appropriate. Wouldn't it be good to rename
the source package? What about moving to assaultcube-nonfree for the source
package name? (Here I'm assuming that the assaultcube-data package was non-free
before, is that correct?) Renaming the source package requires the additional
step of requesting removal of the previous source package from the archives, but
that's doable.

> - Noted (complicates the current deletion of the binaries as well, I
> guess), I've sent the question of special permission for the Debian
> project to the main project people, we'll see where that discussion
> leads.
>

Given your above information about the assaultcube binary package I'm not sure I
understand whether the new "repacknot" package isn't actually license-compliant
as it is unmodified!?

Best regards,
Michael

Attachment: pgphYaG1FLfDk.pgp
Description: PGP signature


Reply to: