Re: Packaging .py files
On Monday 18 August 2008 22:09, wrobell wrote: > On Wed, Jul 16, 2008 at 09:56:00PM +0300, Elan Ruusamäe wrote: > > On Wednesday 16 July 2008 16:07, Patryk Zawadzki wrote: > > > Please no "save the 1k of disk space" arguments. > > > > can the packaging be automated like -debuginfo is right now? > > > > i'd vote for -pysource, -source names :) > > i would use "debuginfo". let's keep one naming convention. i like this idea. however, how to accomplish that? we have %py_postclean macro that removes the .py files. perhaps change that macro to add files to debugfiles.tar instead of removing and in find-debuginfo.sh unpack it? -- glen ___ 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 Wed, Jul 16, 2008 at 09:56:00PM +0300, Elan Ruusamäe wrote: > On Wednesday 16 July 2008 16:07, Patryk Zawadzki wrote: > > Please no "save the 1k of disk space" arguments. > > can the packaging be automated like -debuginfo is right now? > > i'd vote for -pysource, -source names :) i would use "debuginfo". let's keep one naming convention. wrobell <[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 Fri, Jul 18, 2008 at 01:24:13AM +0200, Mariusz Mazur wrote: [...] > 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. sad truth is, that a lot of patches is not sent to project maintainers. this way we need to perform more work while upgrading packages. our problem is communication with outside world and marketing, not pld save-the-world-by-geeks approach. [...] wrobell <[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 07:47:31PM +0200, Patryk Zawadzki wrote:
[...]
> Not to mention the friggin' codegen.{py,pyc} substitution we need to
> do for most of the packages containing bindings.
just propose the patch. if good, i bet it will be accepted. at least
it was always in my case - every patch solving lack of .py files was
applied against sources of given project.
[...]
wrobell <[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:
[...]
> "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.
well, basically format of bytecode files doesn't change between minor
python versions (i.e. 2.5, 2.5.1, 2.5.2...). it changes for major releases,
i.e. 2.5 -> 2.6. but then, still you have to recompile all the packages
because of directory hierarchy change
/usr/{lib,share}/python2.5 -> /usr/{lib,share}/python2.6
[...]
wrobell <[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 Fri, Jul 18, 2008 at 01:24:13 +0200, Mariusz Mazur wrote: > > pld-specific patches makes it harder to maintain PLD so in specific cases > Some stats (that's HEAD): [...] > This means 37% of our spec files are patched with each of those speces having > almost 1.5 patch on average. OK, so let's follow Debian way - one huge patch per package, your stats will feel better then. Please filter out not PLD-specific patches! I gave you bash* stats - 30 patches. -- 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, 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
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: [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: [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: 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 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: [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: 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: 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
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
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: 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
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 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
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 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 Jul 16, 2008, at 6:14 PM, Mariusz Mazur wrote: > >>> All other scripts should be run with >>> what their authors expected, and that's bash (the Have It Just Work >>> rule). The >> >> 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 (b) give a shit. That's a minority. Doing > it 'our > way' is simply pointless (what exactly do we gain?). I prefer to use software written by people who Give A Shit. Aria Stewart [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ł: > 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. So that's top score for theory and a FAIL on the reality check. > > 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). > > Half the time the original developers "don't have a clue", so your > argument fails. Then fix upstream. You have no idea whether they do or don't have a clue if you don't ask first. 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. > > (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. Anything more on point you'd like to add wrt to the python discussion? > > 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? > > All other scripts should be run with > > what their authors expected, and that's bash (the Have It Just Work > > rule). The > > 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 (b) give a shit. That's a minority. Doing it 'our way' is simply pointless (what exactly do we gain?). -- 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 12:30:40AM +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) Yes, condoning bad code practices is the way to go. Go install your ubuntu. > 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). Half the time the original developers "don't have a clue", so your argument fails. > (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. > The only part where we actually prefer not to have bash is where our own > (made You and who else? > 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 Bullshit. The scripts that expect bash have "#!/bin/bash" in header, not "#!/bin/sh". 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, Tomasz Pala napisał: > On Wed, Jul 16, 2008 at 23:07:38 +0200, Mariusz Mazur wrote: > > Over the years I've grown quite tired of a lot of cases where PLD tries > > to be > > I'm tired too but it is a must have for reliable system. 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) 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). > > smarter then upstream and/or other distros and does something completely > > insignificant differently which results in having to patch up perfectly > > working apps. > > 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. Both the python and /bin/sh cases don't fall under any of the above. Let's try to be specific. > > On the one hand I've got a lot of stuff to make my life easier > > (hey, vserver out of the box!) and on the other there are those little > > pesky oddities. > > If you don't value being The Right Way just use some FC, Debian, Ubuntu > or other. 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) and actual standards (python -- I'm quite sure it's authors never meant for it to be distributed the way we do) both break the rule. > > (Others would be e.g. /bin/sh) > > Yeah, let's use fucked up bash. The next step would be to use FC spec > files and simple package - * instead of file listings in subpackages. > The end of this road is even much simplier - ./configure; make; make > install. The only part where we actually prefer not to have bash is where our own (made 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 solution is quite trivial -- have our scripts invoke pdksh directly and leave bash under /bin/sh. 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. 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. -- 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 Wed, Jul 16, 2008 at 23:07:38 +0200, Mariusz Mazur wrote: > Over the years I've grown quite tired of a lot of cases where PLD tries to be I'm tired too but it is a must have for reliable system. > smarter then upstream and/or other distros and does something completely > insignificant differently which results in having to patch up perfectly > working apps. These 'perfectly working apps' used to be security holes, functionality breakers etc. > On the one hand I've got a lot of stuff to make my life easier > (hey, vserver out of the box!) and on the other there are those little pesky > oddities. If you don't value being The Right Way just use some FC, Debian, Ubuntu or other. > Python packaging is one such case. That's one I don't care for much. > (Others would be e.g. /bin/sh) Yeah, let's use fucked up bash. The next step would be to use FC spec files and simple package - * instead of file listings in subpackages. The end of this road is even much simplier - ./configure; make; make install. -- 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: vim-rt size (was Re: Packaging .py files)
On Wed, Jul 16, 2008 at 23:56:08 +0300, Elan Ruusamäe wrote:
>> Use excludedocs Luke.
>
> /usr/share/vim/vim71/doc is not marked as %doc.
Isn't it?
~: du -sh /usr/share/vim/vim71/doc
280K/usr/share/vim/vim71/doc
%doc %{_datadir}/vim/v*/doc/*.txt
%lang(pl) %doc %{_datadir}/vim/v*/doc/*.plx
> it's not online help for vim application (F1 fires it)
I know it is and I have never had it installed on my workstation.
--
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
+1 Over the years I've grown quite tired of a lot of cases where PLD tries to be smarter then upstream and/or other distros and does something completely insignificant differently which results in having to patch up perfectly working apps. On the one hand I've got a lot of stuff to make my life easier (hey, vserver out of the box!) and on the other there are those little pesky oddities. Python packaging is one such case. (Others would be e.g. /bin/sh) -- 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: vim-rt size (was Re: Packaging .py files)
On Wednesday 16 July 2008 23:07, Tomasz Pala wrote: > > as i have few systems where /usr is really small and can't be grown . (do > > not ask why), but i like vim, mostly due it's syntax hiliting feature. > > Use excludedocs Luke. /usr/share/vim/vim71/doc is not marked as %doc. it's not online help for vim application (F1 fires it) -- glen ___ 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 Wed, Jul 16, 2008 at 21:56:00 +0300, Elan Ruusamäe wrote: > can the packaging be automated like -debuginfo is right now? > > i'd vote for -pysource, -source names :) +1 -- 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: vim-rt size (was Re: Packaging .py files)
On Wed, Jul 16, 2008 at 22:00:33 +0300, Elan Ruusamäe wrote: > i'm also thinking perhaps create -doc subpackage. It's only 5MB... > as i have few systems where /usr is really small and can't be grown . (do not > ask why), but i like vim, mostly due it's syntax hiliting feature. Use excludedocs Luke. -- 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
vim-rt size (was Re: Packaging .py files)
On Wednesday 16 July 2008 19:57, Patryk Zawadzki wrote: > On these systems 10MB is the same as 1k. can vim-rt files be compressed somehow? i know vim can read .gz files and write them, can it do same for help/ and syntax/ files i'm also thinking perhaps create -doc subpackage. as i have few systems where /usr is really small and can't be grown . (do not ask why), but i like vim, mostly due it's syntax hiliting feature. -- glen ___ 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 Wednesday 16 July 2008 16:07, Patryk Zawadzki wrote: > Please no "save the 1k of disk space" arguments. can the packaging be automated like -debuginfo is right now? i'd vote for -pysource, -source names :) -- glen ___ 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 Wednesday 16 of July 2008, 15:07, Patryk Zawadzki wrote: > Hi, > > Following up on a Jabber discussion with arekm I'd like to start > packaging .py files along with their bytecode counterparts. Then put them in separate packages, named python-FOO-src or sth like that. [...] -- Tomasz Wittner ___ 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 Wed, Jul 16, 2008 at 6:49 PM, Jakub Bogusz <[EMAIL PROTECTED]> wrote:
> (moving to -en)
> On Wed, Jul 16, 2008 at 03:31:41PM +0200, Patryk Zawadzki wrote:
>> On Wed, Jul 16, 2008 at 3:17 PM, Mateusz Korniak <[EMAIL PROTECTED]> wrote:
>> > On Wednesday 16 of July 2008, Patryk Zawadzki wrote:
>> >> I'd like to start
>> >> packaging .py files along with their bytecode counterparts. The
>> >> reasoning:
>> >>
>> >> 1) It's much easier to find bugs in your own code (...)
>> >>
>> >> 2) It's much easier to trace faulty applications (...)
>> >>
>> >> 3) We'll no longer need to patch multiple applications that either use
>> >> codegen.py (patches for this are all over the place) or use
>> >> glob("*.py") to find their plugins.
>> >>
>> >> I'm not planning a mass commit or anything but I'll start packaging
>> >> the sources instead of removing them when commiting from now on.
>> >>
>> >> Please no "save the 1k of disk space" arguments.
>> >
>> > We can pack *.py and *.pyo (instead of *.pyc *.pyo) archiving almost same
>> > and
>> > having "save the 1k of disk space" ;)
>>
>> Yeah, having .pyc files next to their optimized versions would be useless.
>
> That's false, replacing .pyc with .py is very bad idea.
Then we can/should package them all. I don't want to fix correct code
to look for .pyc files instead of .py (all packages using codegen).
> 1. .pyo files are used only when python is called with -O option.
True, sorry but I'm in zombie state today due to weather changes (no,
coffee does not help).
> 2. if module .pyc file is not present, python (called without -O) attempts
> to write it - so using some python module with root privileges would
> create .pyc files not belonging to any package
Also true.
> And when presenting your idea, use real numbers, not disdained "1k".
> I bet it's about 10-20MB on average system (depending on usage of some
> GNOME/KDE python applications or python frameworks like Twisted or
> Django).
On these systems 10MB is the same as 1k.
--
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: Packaging .py files
(moving to -en)
On Wed, Jul 16, 2008 at 03:31:41PM +0200, Patryk Zawadzki wrote:
> On Wed, Jul 16, 2008 at 3:17 PM, Mateusz Korniak <[EMAIL PROTECTED]> wrote:
> > On Wednesday 16 of July 2008, Patryk Zawadzki wrote:
> >> I'd like to start
> >> packaging .py files along with their bytecode counterparts. The
> >> reasoning:
> >>
> >> 1) It's much easier to find bugs in your own code (...)
> >>
> >> 2) It's much easier to trace faulty applications (...)
> >>
> >> 3) We'll no longer need to patch multiple applications that either use
> >> codegen.py (patches for this are all over the place) or use
> >> glob("*.py") to find their plugins.
> >>
> >> I'm not planning a mass commit or anything but I'll start packaging
> >> the sources instead of removing them when commiting from now on.
> >>
> >> Please no "save the 1k of disk space" arguments.
> >
> > We can pack *.py and *.pyo (instead of *.pyc *.pyo) archiving almost same
> > and
> > having "save the 1k of disk space" ;)
>
> Yeah, having .pyc files next to their optimized versions would be useless.
That's false, replacing .pyc with .py is very bad idea.
1. .pyo files are used only when python is called with -O option.
2. if module .pyc file is not present, python (called without -O) attempts
to write it - so using some python module with root privileges would
create .pyc files not belonging to any package
And when presenting your idea, use real numbers, not disdained "1k".
I bet it's about 10-20MB on average system (depending on usage of some
GNOME/KDE python applications or python frameworks like Twisted or
Django).
--
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
Packaging .py files
Hi,
Following up on a Jabber discussion with arekm I'd like to start
packaging .py files along with their bytecode counterparts. The
reasoning:
1) It's much easier to find bugs in your own code (or the code you're
packaging at the moment) when the libraries are available at hand
(currently I'm forced to do `builder -bp python-foo`).
2) It's much easier to trace faulty applications when you can just
copy the path from a traceback and open the file in vim (yes, yes, or
emacs).
3) We'll no longer need to patch multiple applications that either use
codegen.py (patches for this are all over the place) or use
glob("*.py") to find their plugins.
I'm not planning a mass commit or anything but I'll start packaging
the sources instead of removing them when commiting from now on.
Please no "save the 1k of disk space" arguments.
--
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
