Packaging .py files

[Tomasz Pala]

On Thu, Jul 17, 2008 at 00:30:40 +0200, Mariusz Mazur wrote:

> It's not a reliable system when any application can fail because it either 
> expects something that all of the other distros, except us, have (sh -> bash) 
  ^^^^^^^

Unfortunately these apps do not expect anything - they have some piece
of code just because it have worked while typing in dumb monkey-mode.
I'd prefer not to use such apps as they are (let me repeat) serious
security threat.

Do you remember a situation a few years ago when some malicious code was
inserted into ./configure script? PLD was not affected thanks to another
PITA - AC/AM regeneration.

> or we've done something to it without having much clue about original 
> developers' reasons for a particular choice (ripping out internal versions of 
> various libs).

So just use binary shipped FF, OOo and other.
And BTW it's not their choice again - they exist because of the same
dumb monkey-mode coding.
The Real Programmer ships patch for mainstream lib (like it was in FUR
and librapi2), unless this library is seriously broken - in this case it
shoudn't be used anyway.

> If they in fact are, to the extent we're not as much of security zealots as, 
> say, openbsd, it's obviously better to patch them.

Doesn't our patches go upstream? If they are rejected it usualy means,
that authors are really dumb or don't give a shit. Either way we do The
Right Thing.

> Both the python and /bin/sh cases don't fall under any of the above. Let's try 
> to be specific.

OK, last time:      bash      is         broken. I don't want this
GNU/shitty shell even to be installed on my machines, unfortunatelly some
idiots use its 'features', just because they are too lazy to read SUSv3
spec (like using ((var++)) instead of var=$((var+1))).

> PLD also has The Right Way, the Have It Just Work rule. Non-interactive rpm 
> installations, sane and working out-of-the-box default configs, a lot 
> of %post scripts to make sure everything's integrated, etc, etc. Going 
> against de facto standards (/bin/sh)

It is not de facto or not standard - I don't remember having it on some
HP or AIX machines.

> in-house) scripts are concerned. All other scripts should be run with what 
> their authors expected, and that's bash (the Have It Just Work rule). The 

I don't remember changing /bin/bash to be something different. And that
is used when author EXPECTS it.

> solution is quite trivial -- have our scripts invoke pdksh directly and leave 
> bash under /bin/sh.

No - Have It Just Work rule is trivial other way: if a script is too messed
just change bang line to bash. Bash seems not to care much of argv[0].

> Bottom line is -- we're quite an invasive distro anyway, as far as patching 
> apps goes, so it's in our best interest to get rid of those modifications 
> that have no real life value and are only a pain in the ass.

/bin/sh has the same value as:
1. being FHS compliant
2. micropackages
3. spec files guidelines
4. lang() and %doc stuff

> I'd urge the Th RM (well, Ti too ;) to Do The Right Thing wrt to both python 
> and sh/bash. If it's really an unpopular decision, it'll get overruled in 
> CDG. And if not, we'll have a few less quirks to irritate us.

And you will have a few developers and users left, as PLD would have
still less and less to offer.

-- 
Tomasz Pala <gotar at pld-linux.org>