On Sun, Jan 22, 2017 at 10:49 AM, Markus Koschany <a...@debian.org> wrote: >> On 22.01.2017 19:30, shirish शिरीष wrote: >>> Package: unknown-horizons >>> Version: 2017.1+ds-2 >>> Severity: wishlist >>> >>> Dear Maintainer, >>> Right now what happens is if there are any change/s to the depends or >>> recommends then the unknown-horizons binary gets downloaded each time. >>> This is waste of time and bandwidth from the user as well as Debian's >>> server/mirror perspective. >>> >>> It would be much better and much more highly efficient (probably) if >>> we have a small program which deals with all or any changes with >>> depends or recommends. >>> >>> Unknown-horizons binary should only be disturbed when the change >>> directly affects unknown-horizons, otherwise not. > > This is the way how it works in Debian and not a bug in unknown-horizons > by the way. If you make a change to the source package regarding > build-dependencies or dependencies then it must be rebuilt because > information about dependencies are stored in your deb file. > > Your "small program" still needs to know what has changed and retrieve > the information from somewhere, a database maybe. You need to implement > this change so that all packages in the archive will continue to work. > Not a small feat. You should discuss this with the maintainer(s) of dpkg > or on a public mailing list. Unknown-Horizons is the wrong package though.
Strictly speaking, you can accomodate this request by splitting up src:unknown-horizons into two separate source packages, one which builds a binary deb that contains the game binary. the other which builds a binary deb containing all the game data. The only issue with this approach is that I personally hate mangling upstream source tarballs, so I only do this if upstream releases separate source tarballs for the game engine and data (e.g. src:0ad and src:0ad-data). Punting it over to dpkg's side of the fence is unnecessary IMHO (and I don't think there's anything reasonable that can be done on the dpkg side of things that wouldn't be better implemented using the split source package approach). Regards, Vincent
