Bug#696385: RFS: astromenace/1.3.1+ds-1 [ITP] -- hardcore 3D space shooter with spaceship upgrade possibilities
Hi again,
> However, I have an alternative proposal which would avoid the problem
> and should not impose too much hassle on you: ship the entire source in
> astromenace-data, build the executable there, use it to package the
> data, but do not ship the built executable.
Thank you for the interesting proposal. But I do not think that this is a good
solution here.
Package astromenace has some debian-specific patches [1]. Proposed solution
implies that they should be shipped in both packages. Also debian/rules in
astromenace-data will be longer and less clean/transparent than now.
[1] http://anonscm.debian.org/gitweb/?p=pkg-games/astromenace.git;a=tree;f=debian/patches
> This way, astromenace-data does not need to build-depend on astromenace,
> which can rightfully Depend on astromenace-data. You don't need to
> bootstrap by first only Recommending astromenace-data.
This will be done only at first upload. I do not see the reason to avoid it.
Do you have one?
Moreover, one idea have just came into my mind. If you have already built
astromenace-data, you can upload it as is. And astromenace package can be
modified even before first upload, so it will depend on astromenace-data
when it is added to archive.
Problem with circular dependencies affects only to build system of potential
sponsor of the package because:
a) astromenace-data is arch-indep package and such packages are not re-built
by buildd;
b) packages in non-free are not re-built by buildd.
Thus I propose such solution:
1) You use current (unmodified) package astromenace to build astromenace-data.
2) I update package astromenace: it will depend on astromenace-data.
(But without changing package version.)
3) You upload package astromenace-data and updated package astromenace.
If you agree with this tricky/artful solution I will prepare updated package
astromenace this evening.
Best regards,
Boris
Reply to: