[Distutils] bdist_deb in stdeb

[Gerry Reno]

Andrew Straw wrote:
> Gerry Reno wrote:
>   
>> What if stdeb only had the command 'bdist_deb' and had no other command.
>>     
>
> I will not remove the "sdist_dsc" command from stdeb. I believe that the
> ability to produce debian source packages is much more important that
> the ability to produce binary packages which only target a single
> architecture and version of Debian/Ubuntu. "bdist_deb" is just a trivial
> add-on to that saving a couple lines of typing which may be helpful to
> people who aren't familiar with those lines. But I see the .dsc and
> associated files as much more useful as the compiled .deb files.
>
>
>   
LMAO.  Dang it.  I am not suggesting or implying that you should remove 
the 'sdist_dsc' command.  I'm trying to illustrate that the 
commandA-opts are just that and nothing more: commandA-opts.  And 
whatever part of the build/install process that they apply to, then the 
commandA can use them for WHATEVER purpose.  Which means that since 
'bdist_deb' calls 'sdist_dsc' it is perfectly ok to allow all 
'sdist_dsc' options to be passed into the 'bdist_deb' command which can 
then pass them along to 'sdist_dsc'.  'bdist_deb' is a SUPERSET of 
'sdist_dsc'.


>> Everything else was taken care of internally.  What then?  Are you
>> saying then that it is impossible to pass in any options to
>> 'bdist_deb' to affect the generation of the source package?  If true,
>> this makes NO SENSE.
>>     
> I still don't understand why you insist the options are to the bdist_deb
> command. What is wrong with passing the options to the sdist_dsc command
> where they take effect anyway?
>
>
>   
>> Yes, I can see that once we got invaded with setuptools it seems you
>> really have no other choice.
>>     
> Hang on a minute. The "st" in stdeb is for "setuptools". While in the
> 0.4 version this may take a less prominent role, and Distribute might be
> able to step in, the ontogeny of stdeb is very much tied up with
> setuptools. So I'm not comfortable promoting the idea that there ever
> existed stdeb without setuptools. Maybe it can happen in the future --
> but it's certainly never happened in the past.
>   
I never said that stdeb ever existing in any other form but that of 
using setuptools.  I was merely making a statement as to the impact that 
this has.

>   
>> And getting back to the issue that got skipped:
>> Another issue:  In util.py on line 962 (gerry-reno git):
>> %(setup_env_vars)spython$* -c "import
>> setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})"
>> install \\
>>
>> Maybe it should be like this (note semicolon splitting line into two
>> statements):
>> %(setup_env_vars)s;    python$* -c "import
>> setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})"
>> install \\
>>
>> Otherwise any of the env vars don't seem to be in effect for the  line
>> itself.   If you put any of the env vars in the line, they don't
>> expand to the value set in set_env_vars.  They expand to previous
>> value or to null.
>>     
> For setting environment variables this way, they cannot be separated by
> a semicolon
The environment variables are not individually separated by a 
semicolon.  The WHOLE shell script environment variable declaration 
statement needs to be separated from the install line statement.

Simple demonstration of the problem with the 'echo' statement simulating 
the 'install' statement:
$ a='123' b='456' echo test $a $b
test
$ a='123' b='456'; echo test $a $b
test 123 456


Regards,
Gerry