Re: Packaging .py files
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 [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Packaging .py files
On Thu, Jul 17, 2008 at 01:45:39 +0200, Bartosz Taudul wrote: The more I know about python the more I am assured it's a joke language. I felt the same when saw it's promo movie. -- Tomasz Pala [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Packaging .py files
On Thu, Jul 17, 2008 at 02:14:35 +0200, Mariusz Mazur wrote: Bullshit. The scripts that expect bash have #!/bin/bash in header, not #!/bin/sh. That's true only for the scripts whose authors (a) know there are distros that don't use bash as sh and FALSE using /bin/sh means using ANY POSIX shell. Oh, BTW your 'de facto standard' reminds me Microsoft HTML - 'de facto standard' with Microsoft extensions and incompatibilities with HTML. (b) give a shit. That's a minority. Doing it 'our way' is simply pointless (what exactly do we gain?). The same as with AC/AM regeneration, getting rid of internal libs, recompiling packages (hey, there are binaries available at websites, isn't it?), keeping of FHS, separating *debuginfo*, *devel*, *static* lang(), %doc etc etc. Let's put entire KDE4, GNOME and OOo into /opt (who gives a shit? It Just Works). Let programs keep their configuration in /usr/local/bin/etc (who gives a shit? It Just Works!). I suggest discussing it all together with changing template.spec (it's enough to unpack original binary and put them into %files section) and changing distro name to PLbuntu (hey, small 'b' letter looks like 'D'!). -- Tomasz Pala [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Packaging .py files
2008/7/17 Mariusz Mazur [EMAIL PROTECTED]: Yes, condoning bad code practices is the way to go. Go install your ubuntu. It's bad in theory. In practice, for the past mny years nobody gives a shit about theory in case of /bin/sh. Bad for them. So that's top score for theory and a FAIL on the reality check. Flushing quality down the toilet is not an option. Half the time the original developers don't have a clue, so your argument fails. Then fix upstream. The number of sane developers without inferiority complex is very low and I don't like to talk with idiots if I don't have to. I'd rather default to assuming that the guys who wrote the stuff know better than Joe Random Developer does. I'm actually *using* their code, so I kind of assume they have some kind of clue. I actually have enough *experience* to *know* that most of the time they don't. (python -- I'm quite sure it's authors never meant for it to be distributed the way we do) The more I know about python the more I am assured it's a joke language. That's not an argument. Running debug code by default and requiring special knobs for having release code ran is kind of funny if I don't have to use it. The only part where we actually prefer not to have bash is where our own (made in-house) scripts are concerned. You and who else? And concerning the point of that sentence? Anything you'd like to say? Maybe that it's false or sth? With some specific reasons as to why? Of course it's false. You are speaking strictly for yourself, yet you are manipulating everyone to think that's a widely applauded opinion (by using we instead of I). Bullshit. The scripts that expect bash have #!/bin/bash in header, not #!/bin/sh. That's true only for the scripts whose authors (a) know there are distros that don't use bash as sh You were saying something about developers having a clue recently? (b) give a shit. We know that you don't. Doing it 'our way' is simply pointless Our way? https://wiki.ubuntu.com/DashAsBinSh (what exactly do we gain?). Speed, correctness, etc. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Packaging .py files
On Thu, Jul 17, 2008 at 11:24:24 +0200, Bartosz Taudul wrote: Doing it 'our way' is simply pointless Our way? https://wiki.ubuntu.com/DashAsBinSh And at this point we could end this discussion or change it's subject to 'pdksh or dash'. One more example of 'giving a damn shit about correctness' for MM: gcc. -- Tomasz Pala [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Packaging .py files
Dnia czwartek, 17 lipca 2008, Bartosz Taudul napisał:
The number of sane developers without inferiority complex is very low
and I don't like to talk with idiots if I don't have to.
That's why I prefer not to have too many pld specific changes, since it's
easier to merge something upstream when you can point at a major distro and
say that the current way also breaks on e.g. Fedora.
Doing it 'our way' is simply pointless
Our way? https://wiki.ubuntu.com/DashAsBinSh
Ok, that's enough for me if there are other mainstream distros that don't use
bash.
Regarding original thread, I'm still in favor of packaging *.py files in base
packages.
One other option to consider. According to this document:
http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html
Debian does the following:
If a package provides any binary-independent modules (foo.py files), the
corresponding bytecompiled modules (foo.pyc files) and optimized modules
(foo.pyo files) must not ship in the package. Instead, they should be
generated in the package's postinst, and removed in the package's prerm. The
package's prerm has to make sure that both foo.pyc and foo.pyo are removed.
This obviously makes installation a bit slower, but has the advantage of being
python-version independent, meaning when you upgrade python, you don't have
to rebuild all python-dependant packages and reinstall them -- postinst
scripts just rebuild *.py{c,o} files on your system and you're done.
Major problem -- it's slower.
--
Judge others by their intentions and yourself by your results.
Guy Kawasaki
Education is an admirable thing, but it is well to remember from
time to time that nothing that is worth knowing can be taught.
Oscar Wilde
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [ANNOUNCEMENT] Bugzilla /dev/null, switching to launchpad.net
Dnia środa, 16 lipca 2008, Adam Gołębiowski napisał: It looks like launchpad doesn't send mail reports to [EMAIL PROTECTED], please fix this. I need the cooperation of the moderator first. Who might that be? -- Judge others by their intentions and yourself by your results. Guy Kawasaki Education is an admirable thing, but it is well to remember from time to time that nothing that is worth knowing can be taught. Oscar Wilde ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Packaging .py files
Dnia czwartek, 17 lipca 2008, Tomasz Pala napisał: 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. I know, my point is, that there are specific cases, where an 'error' is too widespread to try to fix everything and it might make more sense to just stop enforcing our way and do what everybody else does. On the other hand, I'm quite attached to PLD being for example FHS-strict. So just use binary shipped FF, OOo and other. I use ux-oo, because a long time ago I got tired of our OO blowing up every second upgrade. I really do think that such integration nightmares as OO or, dunno, big java apps (especially considering java has it's own standards for allmost everything and you don't gain anything by recompiling bytecode) aren't worth trying to force our ways onto and it makes more sense to make more of an effort to accommodate the stuff that's released by upstream. It's a separate discussion though. 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. At a certain complexity level it might not just be possible/worth it, to do it The Right Way. 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. A) Authors often have different goals then distributions, especially non-mainstream ones, like PLD. So I'd guess more often then not, they'd be saying we're the idiots. B) We can't save the world. Having more and more pld-specific patches makes it harder to maintain PLD so in specific cases it might make more sense to just give up and do what everybody else does. And you will have a few developers and users left, as PLD would have still less and less to offer. I'm in favor of PLD being a compromise between being a geek's dream and something that's actually usable without having to patch your way trough every app. -- Judge others by their intentions and yourself by your results. Guy Kawasaki Education is an admirable thing, but it is well to remember from time to time that nothing that is worth knowing can be taught. Oscar Wilde ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Packaging .py files
On Thu, Jul 17, 2008 at 17:17:21 +0200, Mariusz Mazur wrote: I know, my point is, that there are specific cases, where an 'error' is too widespread to try to fix everything and it might make more sense to just stop enforcing our way and do what everybody else does. On the other hand, I'm quite attached to PLD being for example FHS-strict. Our policy seems to be the winning one - not only other distros try harder to keep standards, app developers too. Have you ever faced rejecting some bashizm patch? World wants to be standarized, it's popular. second upgrade. I really do think that such integration nightmares as OO or, dunno, big java apps (especially considering java has it's own standards for allmost everything and you don't gain anything by recompiling bytecode) aren't worth trying to force our ways onto and it makes more sense to make more of an effort to accommodate the stuff that's released by upstream. It's a separate discussion though. I agree. Because in this case we are 'dumb monkeys' trying to recompile everything. However it's not /bin/sh case. At a certain complexity level it might not just be possible/worth it, to do it The Right Way. Fixing bashizm is not complex. After all one can change just bang line. I'm far from making Oracle FHS-compliant. 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. A) Authors often have different goals then distributions, especially Shell scripts are usually beyond any goals, they exist just because they are handy. non-mainstream ones, like PLD. So I'd guess more often then not, they'd be saying we're the idiots. Some examples of rejecting bashizm patch? B) We can't save the world. Having more and more pld-specific patches makes it harder to maintain PLD so in specific cases it might make more sense to just give up and do what everybody else does. FHS is much more complex than bash/pdksh issues, as well as handling compressed %doc in internal help browsers. I'm in favor of PLD being a compromise between being a geek's dream and something that's actually usable without having to patch your way trough every app. There's only ca. 30 bash related patches in SOURCES. It's not every app. -- Tomasz Pala [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Packaging .py files
On Thu, Jul 17, 2008 at 04:50:24PM +0200, Mariusz Mazur wrote:
Dnia czwartek, 17 lipca 2008, Bartosz Taudul napisał:
The number of sane developers without inferiority complex is very low
and I don't like to talk with idiots if I don't have to.
That's why I prefer not to have too many pld specific changes, since it's
easier to merge something upstream when you can point at a major distro and
say that the current way also breaks on e.g. Fedora.
Doing it 'our way' is simply pointless
Our way? https://wiki.ubuntu.com/DashAsBinSh
Ok, that's enough for me if there are other mainstream distros that don't use
bash.
And remember that most of software we use (except some system tools)
could be used on UNIX, not just Linux.
Is there any other OS (beside some Linux distros and Hurd) which uses
bash as sh?
On *BSD, Solaris, AIX etc. there is even no /bin/bash (in most cases you
can find it in /usr/local/bin, if GNU tools are installed).
Regarding original thread, I'm still in favor of packaging *.py files in base
packages.
One other option to consider. According to this document:
http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html
Debian does the following:
If a package provides any binary-independent modules (foo.py files), the
corresponding bytecompiled modules (foo.pyc files) and optimized modules
(foo.pyo files) must not ship in the package. Instead, they should be
generated in the package's postinst, and removed in the package's prerm. The
package's prerm has to make sure that both foo.pyc and foo.pyo are removed.
This obviously makes installation a bit slower, but has the advantage of
being
python-version independent, meaning when you upgrade python, you don't have
to rebuild all python-dependant packages and reinstall them -- postinst
scripts just rebuild *.py{c,o} files on your system and you're done.
Major problem -- it's slower.
Major problem is that there is no way to verify *.pyc consistency
against package database. One can place any malicious code in *.pyc
leaving *.py untouched and it's hard to detect.
That's why I don't like the Debian way.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [OT] Packaging .py files
Mniej wiecej Thu, Jul 17, 2008 at 12:30:40AM +0200, zainteresowany Mariusz Mazur rzekl: Dnia czwartek, 17 lipca 2008, Tomasz Pala napisał: These 'perfectly working apps' used to be security holes, functionality breakers etc. 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. http://tinyurl.com/6cxdjw Are you sure? ;) Zbyniu -- %% Absolutely nothing we trust %% ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [ANNOUNCEMENT] Bugzilla /dev/null, switching to launchpad.net
2008/7/17 Mariusz Mazur [EMAIL PROTECTED]: Dnia środa, 16 lipca 2008, Adam Gołębiowski napisał: It looks like launchpad doesn't send mail reports to [EMAIL PROTECTED], please fix this. I need the cooperation of the moderator first. Who might that be? Moderator of what? -- Patryk Zawadzki PLD Linux Distribution ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [ANNOUNCEMENT] Bugzilla /dev/null, switching to launchpad.net
Dnia czwartek, 17 lipca 2008, Patryk Zawadzki napisał: 2008/7/17 Mariusz Mazur [EMAIL PROTECTED]: Dnia środa, 16 lipca 2008, Adam Gołębiowski napisał: It looks like launchpad doesn't send mail reports to [EMAIL PROTECTED], please fix this. I need the cooperation of the moderator first. Who might that be? Moderator of what? [EMAIL PROTECTED] In order to subscribe. I think. -- Judge others by their intentions and yourself by your results. Guy Kawasaki Education is an admirable thing, but it is well to remember from time to time that nothing that is worth knowing can be taught. Oscar Wilde ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [OT] Packaging .py files
Dnia 2008-07-17, czw o godzinie 18:10 +0200, Zbyniu Krzystolik pisze: Mniej wiecej Thu, Jul 17, 2008 at 12:30:40AM +0200, zainteresowany Mariusz Mazur rzekl: Dnia czwartek, 17 lipca 2008, Tomasz Pala napisał: These 'perfectly working apps' used to be security holes, functionality breakers etc. 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. http://tinyurl.com/6cxdjw Are you sure? ;) ROTFL! reddit, digg, slashdot, wykop anyone? ; -- DeeJay1 ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Packaging .py files
2008/7/17 Jakub Bogusz [EMAIL PROTECTED]:
And remember that most of software we use (except some system tools)
could be used on UNIX, not just Linux.
That's true. And it's also true we are now forced by our own policies
to fix stuff that *might* become a future issue to some obscure *NIX
implementation. I'm not against going for a perfect world. I'm against
being forced to do something counter-productive in order to get some
work done (and I'm fairly sure I'm not the only one to package stuff
that I actually need).
In other words - we are one of the most limited distros when it comes
to resources. Pursuing a dream is one thing but we should not be
forced to do it. I'm not sure I want to lose my job for the sake of
saving the world. I want to be able to easily install a package and
get the goddamn python sources. Sure pydoc is useful but it's only
useful to the extent man is - you have to know the name of the
function in which case you probably don't need pydoc anymore (API
changes or implementation details that change but some coder decided
to rely on).
Not to mention the friggin' codegen.{py,pyc} substitution we need to
do for most of the packages containing bindings.
Is there any other OS (beside some Linux distros and Hurd) which uses
bash as sh?
Is there any PSD Solaris Distribution? (same kind of question)
--
Patryk Zawadzki
PLD Linux Distribution
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [OT] Packaging .py files
Dnia czwartek, 17 lipca 2008, Łukasz Jernaś napisał: http://tinyurl.com/6cxdjw Are you sure? ;) ROTFL! reddit, digg, slashdot, wykop anyone? ; Yes. A few days ago. Old news. -- Judge others by their intentions and yourself by your results. Guy Kawasaki Education is an admirable thing, but it is well to remember from time to time that nothing that is worth knowing can be taught. Oscar Wilde ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [OT] Packaging .py files
Dnia 2008-07-17, czw o godzinie 19:56 +0200, Mariusz Mazur pisze: Dnia czwartek, 17 lipca 2008, Łukasz Jernaś napisał: http://tinyurl.com/6cxdjw Are you sure? ;) ROTFL! reddit, digg, slashdot, wykop anyone? ; Yes. A few days ago. Old news. Buuu, missed that one :/ -- DeeJay1 ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Packaging .py files
On Thu, Jul 17, 2008 at 07:47:31PM +0200, Patryk Zawadzki wrote: I'm against being forced to do something counter-productive in order to get some I'm against being forced to have some shit installed on my computer that only some lazy developer needs. In other words - we are one of the most limited distros when it comes to resources. We will surely have more people power if we start lowering quality and blending with other distros. Pursuing a dream is one thing but we should not be forced to do it. I'm not sure I want to lose my job for the sake of saving the world. Since when does PLD care about your job (or mine)? Saying that your personal needs should come before general distros needs is extremely arrogant IMO. I want to be able to easily install a package and get the goddamn python sources. So install your python debuginfo equivalent and stop bitching. Why should everyone be forced to have your crap, when they're just fine with already compiled bytecode? Sure pydoc is useful but it's only useful to the extent man is - you have to know the name of the function in which case you probably don't need pydoc anymore (API changes or implementation details that change but some coder decided to rely on). Yes, yes, very interesting. I will start packaging all the sources of C libraries into main packages then, just so I can check if the code really, *really*, *REALLY* does what the documentation and/or man pages say. That's my favourite pastime activity, you know. I do it for the kicks. wolf -- Bartek . Taudul : .: w o l f @ p l d - l i n u x . o r g.:. http://wolf.valkyrie.one.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Packaging .py files
Dnia czwartek, 17 lipca 2008, Mariusz Mazur napisał: B) We can't save the world. Having more and more pld-specific patches makes it harder to maintain PLD so in specific cases it might make more sense to just give up and do what everybody else does. Some stats (that's HEAD): [EMAIL PROTECTED] SPECS]$ ls |grep spec$|wc -l 13023 [EMAIL PROTECTED] SPECS]$ grep ^Patch -r .|wc -l 11841 [EMAIL PROTECTED] SPECS]$ egrep '^%patch|:%patch' -r .|wc -l 11470 [EMAIL PROTECTED] SPECS]$ grep -c ^Patch -r .|grep -c ':0$' 8226 This means 37% of our spec files are patched with each of those speces having almost 1.5 patch on average. And now the same stats but only for packages that are currently found in 3.0 (both in main and in ready/test/updates/whatever; note the list isn't perfect). [EMAIL PROTECTED] THSPECS]$ ls *.spec|wc -l 5761 [EMAIL PROTECTED] THSPECS]$ grep ^Patch -r .|wc -l 5600 [EMAIL PROTECTED] THSPECS]$ egrep '^%patch|:%patch' -r .|wc -l 5445 [EMAIL PROTECTED] THSPECS]$ grep -c ^Patch -r .|grep -c ':0$' 3856 This means that Th contains ~45% of potential (in pure theory) packages available in PLD. Additionally: 67% of Th packages are patched with also almost 1.5 patches on average. At http://ep09.pld-linux.org/~mmazur/pld/thlist.txt is a list of spec files I've used, should anyone be interested in, dunno, maybe generating the same numbers for the past two years (monthly intervals) and plotting that? -- Judge others by their intentions and yourself by your results. Guy Kawasaki Education is an admirable thing, but it is well to remember from time to time that nothing that is worth knowing can be taught. Oscar Wilde ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
