Hi Cameron, First of all, thanks for volunteering to package and maintain premake4! One of my packages (0ad) actually uses an embedded copy of premake, which I would like to switch to using a system version if possible, but of course premake4 isn't yet available in Debian...
Just to address some of pabs' questions below: On Mon, Dec 24, 2012 at 8:38 PM, Paul Wise <[email protected]> wrote: > On Tue, Dec 25, 2012 at 10:05 AM, Cameron Hart wrote: > >> I have been reading through the intro-maintainers page and linked >> documentation. One thing I haven't explicitly come across is renaming >> executables. >> >> The upstream Premake package renamed their executable from 'premake' >> in Premake 3.7 to 'premake4' in Premake 4.0. Are there any issues I >> should be aware of around executable names changing when upgrading >> from upstream? > > I'm not sure about with premake, but there are several places where > executable names are stored apart from in the package itself: > > In the brains of users. This is probably not an issue since most > people use tab completion to type executable names instead of manually > typing them in full. > > In the headers of scripts. This can be a problem since all the scripts > need to be adjusted. If the new version of the language is not > compatible with the input files then this isn't an issue since they > need to be adjusted anyway. If the two versions are compatible there > is zero reason to rename and upstream should revert the change. Premake4 is backwards incompatible with earlier versions, which is why upstream renamed the binary. It also looks for a different input file (premake4.lua instead of premake.lua, in the same sense that cmake looks for CMakeLists.txt and scons looks for Sconstruct in the current directory). In light of this, I suggest having two separate source packages, i.e. src:premake and src:premake4. I say "suggest" instead of something stronger because a) no package currently in the archive build-depends on premake, so nothing's going to FTBFS, and b) I don't know if upstream even maintains the older 3.x version anymore. > In automated build systems and other scripts. Similar issues as above. > > Is this more of a python2 -> python3 transition? or a python 2.6 -> > 2.7 transition? What else changed apart from the executable name? Definitely more like python2 -> python3, as explained above. > Are there many packages using premake in Debian? If so you will want > to request a transition slot after wheezy is released: According to build-rdeps, none. Presumably because there are packages like 0ad which use an embedded copy of premake. (That, or because premake is nowhere as popular as e.g. cmake or scons.) Regards, Vincent -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/caczd_tc5cwjw+26ca1tbq27p6ly_g21z0tc4lpxeaqtq8hy...@mail.gmail.com
