[Distutils] bdist_deb in stdeb
greno at verizon.net
Tue Sep 29 00:03:09 CEST 2009
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
>> 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
>> 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
>> install \\
>> Maybe it should be like this (note semicolon splitting line into two
>> %(setup_env_vars)s; python$* -c "import
>> 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
$ a='123' b='456'; echo test $a $b
test 123 456
More information about the Distutils-SIG