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

Re: Interested in adopting the premake package



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 <pabs@debian.org> 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


Reply to: