Am 20.04.2016 um 00:53 schrieb Ben Finney: > On 19-Apr-2016, Markus Koschany wrote: >> thanks for your update. There are only a few things left before we can >> upload the package. > > Thank you for working with me on this. > >> My main concern is the adventure-common binary package because I >> don't believe that shipping advent.dat with an extra package is very >> useful at the moment. > > Would you decline to upload on that basis? I appreciate you don't > think there's a benefit, but is there any appreciable harm from having > the ‘adventure-common’ package? > >> I think it is cool to have a modern Python3 version but it would be >> rather boring to have identical versions that simply reuse the same >> story from advent.dat. > > My thinking is that the Python 3 package is rather idiosyncratic, and > that I'd like to make it clear the common files are available for > different ports from the original Fortran program. > > I'm not going to insist, but I'd like to know whether you think this > structure is harmful, or only that this isn't the style you would > choose.
I think the word harmful is a bit too strong but I don't think that your current approach is beneficial either. The rationale for providing multiple binary packages is that users should be able to install a subset of an application and save some disk space. In this case they always have to install both packages because otherwise the game would be broken. It would be a different case if they already had a choice and could choose between different variants. Games often provide a significant amount of data and media files and then it really makes sense to split off the data into some arch:all -data or -common package when the architecture dependent data is small compared to the arch-indep part. It would have been extremely wasteful, if I hadn't done that for freeorion. (C++ game, -data package ~150 MB) but in your case the game is already arch:all instead of arch:any and adventure-common is even smaller than colossal-cave-adventure. So another variable must be taken into account: metadata. Every binary package in Debian's archive produces metadata and _every_ user has to fetch this information, for instance with apt when doing a daily update. In your case the performance penalty (even when it's rather small) is greater than the advantage of having a separate -common package which could be reused for a potential and not yet packaged adventure variant. And last but not least the ftp team once rejected an extra -doc package for the game njam because it was very small and insisted to merge it into the -data package. The funny part is that my sponsor back then thought it was a good idea, so the situation was kind of reversed. I wouldn't decline to upload but you should take this wall of text into consideration. In my opinion you can always split the package later when a potential port might require it. [...] >> and that we use cgit for better performance. > > Recently, the default browser on Alioth was switched to Cgit. So, > at <URL:https://anonscm.debian.org/git/collab-maint/dput.git> the Cgit > browser is presented. Indeed they redirect all requests now. I don't know if that comes with a performance penalty though. I wonder why we need two fields, Vcs-Browser and Vcs-Git, if they are identical... Regards, Markus
signature.asc
Description: OpenPGP digital signature
