Re: Bug#128531: tmda
Adam McKenna writes:
> On Wed, Feb 20, 2002 at 12:55:59AM +0100, Matthias Klose wrote:
> > reopen 128531
> > thanks
> >
> > > From: [EMAIL PROTECTED] (Adam D. McKenna)
> > > Changes:
> > > tmda (0.46-1) unstable; urgency=low
> > > .
> > >* New upstream release
> > >* Package split into 3 packages to help attempt to conform to Debian's
> > > braindead Python policy. New packages are:
> > >python-tmda (Python libraries only)
> > >tmda (tmda and configuration files)
> > >python2-tmda (dummy package)
> > > (Closes: Bug#128531, Bug#131294)
> >
> > I really like such ChangeLog entries :-(((
> >
> > If you think, that the proposed Python policy is braindead, then
> > explain why.
> >
> > Your package restructering is braindead on its own and doesn't fix the
> > bug reported. Why adding a python2-tmda dummy package?
>
> Any policy that forces me to compile .py{c,o} object files in my postinst is
> braindead. Then I also have to delete them in purge/postrm, and the
> packaging system knows nothing about them.
In the changelog entry you complained about splitting the package, now
you complain about compiling the .py files. So the changelog entry is
simply false.
You have to remove the compiled python files in the postrm. Call as
root: python -O -c 'import TMDA' and try to remove the package ...
> The dummy package is there so that people already running tmda will get the
> new version automatically. It will be removed in the next revision of the
> package.
This doesn't help. You don't know, from which version someone upgrades.
Package: python-tmda
Conflicts: python2-tmda
Replaces: python2-tmda
Re: Bug#128531: tmda
On Wed, Feb 20, 2002 at 08:06:35AM +0100, Matthias Klose wrote:
> Adam McKenna writes:
> > On Wed, Feb 20, 2002 at 12:55:59AM +0100, Matthias Klose wrote:
> > > reopen 128531
> > > thanks
> > >
> > > > From: [EMAIL PROTECTED] (Adam D. McKenna)
> > > > Changes:
> > > > tmda (0.46-1) unstable; urgency=low
> > > > .
> > > >* New upstream release
> > > >* Package split into 3 packages to help attempt to conform to
> > > > Debian's
> > > > braindead Python policy. New packages are:
> > > >python-tmda (Python libraries only)
> > > >tmda (tmda and configuration files)
> > > >python2-tmda (dummy package)
> > > > (Closes: Bug#128531, Bug#131294)
> > >
> > > I really like such ChangeLog entries :-(((
> > >
> > > If you think, that the proposed Python policy is braindead, then
> > > explain why.
> > >
> > > Your package restructering is braindead on its own and doesn't fix the
> > > bug reported. Why adding a python2-tmda dummy package?
> >
> > Any policy that forces me to compile .py{c,o} object files in my postinst is
> > braindead. Then I also have to delete them in purge/postrm, and the
> > packaging system knows nothing about them.
>
> In the changelog entry you complained about splitting the package, now
> you complain about compiling the .py files. So the changelog entry is
> simply false.
According to this proposed policy, py{c,o} files only need to be compiled in
postinst and removed in postrm if I want to have "A single pachage for all
versions", as described in section 2.2.3.2. I take this to mean that
generating the .py{c,o} files during the package build process is ok if I
only want to support the default version.
> You have to remove the compiled python files in the postrm. Call as
> root: python -O -c 'import TMDA' and try to remove the package ...
Yeah, that's dumb. The reason for having a package management system is to
manage the package files. .py{c,o} files are not platform-dependent, only
python-version dependent. So there should be no problem generating them
during the package build if I only want to support the default version.
Plus, gee, I don't have a bunch of files littering the filesystem that aren't
known to dpkg.
--Adam
--
Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Bug#128531: tmda
On Tue, Feb 19, 2002 at 07:41:05PM -0800, Sean 'Shaleh' Perry wrote: > A program run by a user will never be able to write out the .py[co] files so > the files MUST be generated by the postinst which has root privs. Also we can > not expect the user to be running /usr mount rw except when a package is being > installed. So even if the user is logged in as root they will still be unable > to write the optimized files out. > > What do you have against giving the user optimizations? Absolutely nothing, but I don't see why this needs to be done outside of the package management system. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Bug#128531: tmda
>> >> What do you have against giving the user optimizations? > > Absolutely nothing, but I don't see why this needs to be done outside of > the package management system. > I fail to see why these files need to be known by dpkg? Many python modules are forwards compatible, I also fail to see why supporting more than one version of python is a problem.
Re: Bug#128531: tmda
On Wed, Feb 20, 2002 at 07:57:52AM -0800, Sean 'Shaleh' Perry wrote: | >> | >> What do you have against giving the user optimizations? | > | > Absolutely nothing, but I don't see why this needs to be done outside of | > the package management system. | | I fail to see why these files need to be known by dpkg? Many python modules | are forwards compatible, The bytecode files are version-specific even if the source code isn't. -D -- "...the word HACK is used as a verb to indicate a massive amount of nerd-like effort." -Harley Hahn, A Student's Guide to Unix
Re: Bug#128531: tmda
On 20-Feb-2002 dman wrote: > On Wed, Feb 20, 2002 at 07:57:52AM -0800, Sean 'Shaleh' Perry wrote: >| >> >| >> What do you have against giving the user optimizations? >| > >| > Absolutely nothing, but I don't see why this needs to be done outside of >| > the package management system. >| >| I fail to see why these files need to be known by dpkg? Many python modules >| are forwards compatible, > > The bytecode files are version-specific even if the source code isn't. which was my point. To have multiple version support the object files must be made at install time.
Re: Bug#128531: tmda
On Wed, Feb 20, 2002 at 07:57:52AM -0800, Sean 'Shaleh' Perry wrote: > >> > >> What do you have against giving the user optimizations? > > > > Absolutely nothing, but I don't see why this needs to be done outside of > > the package management system. > > > > I fail to see why these files need to be known by dpkg? Many python modules > are forwards compatible, I also fail to see why supporting more than one > version of python is a problem. They should be known by dpkg because they're part of the package. It's impossible to support more than just the currently installed versions anyway. Once a new version of python is added, the package will still need to be updated or at least reinstalled to compile the modules for the new version. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Bug#128531: tmda
> > They should be known by dpkg because they're part of the package. It's > impossible to support more than just the currently installed versions anyway. > Once a new version of python is added, the package will still need to be > updated or at least reinstalled to compile the modules for the new version. > Adam, that is the whole point of compileall.
Re: Bug#128531: tmda
On Wed, Feb 20, 2002 at 11:19:57AM -0800, Sean 'Shaleh' Perry wrote: > > > > They should be known by dpkg because they're part of the package. It's > > impossible to support more than just the currently installed versions > > anyway. > > Once a new version of python is added, the package will still need to be > > updated or at least reinstalled to compile the modules for the new version. > > Adam, that is the whole point of compileall. That's fine. But as far as I am concerned, my package is compliant as of today. python2-tmda will be removed as of the next update. Unless someone can tell me what part of my package is non-compliant, please close the bug you reopened. When I get some more free time I'll look into supporting more versions of python. By the way, "compileall" is not mentioned in python policy. If you want to set forth a policy, it's usually a good idea to provide a rationale for it, or at least say how things like this will be implemented. If the policy needs updating, then please update it. Thanks, --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Bug#128531: tmda
On Wed, Feb 20, 2002 at 11:08:22AM -0800, Sean 'Shaleh' Perry wrote: | | On 20-Feb-2002 dman wrote: | > On Wed, Feb 20, 2002 at 07:57:52AM -0800, Sean 'Shaleh' Perry wrote: | >| >> | >| >> What do you have against giving the user optimizations? | >| > | >| > Absolutely nothing, but I don't see why this needs to be done outside of | >| > the package management system. | >| | >| I fail to see why these files need to be known by dpkg? Many python modules | >| are forwards compatible, | > | > The bytecode files are version-specific even if the source code isn't. | | which was my point. But you said they are "forward compatible". .pyc files from 1.5.2 won't work with 2.1 or 2.2. | To have multiple version support the object files must be made at | install time. Yeah. -D -- There are six things the Lord hates, seven that are detestable to him : haughty eyes, a lying tongue, hands that shed innocent blood, a heart that devises wicked schemes, feet that are quick to rush into evil, a false witness who pours out lies and a man who stirs up dissension among brothers. Proverbs 6:16-19
Re: Bug#128531: tmda
On Wed, Feb 20, 2002 at 01:16:59AM -0800, Adam McKenna wrote: > On Tue, Feb 19, 2002 at 07:41:05PM -0800, Sean 'Shaleh' Perry wrote: > > A program run by a user will never be able to write out the .py[co] files so > > the files MUST be generated by the postinst which has root privs. Also we > > can > > not expect the user to be running /usr mount rw except when a package is > > being > > installed. So even if the user is logged in as root they will still be > > unable > > to write the optimized files out. > > > > What do you have against giving the user optimizations? > > Absolutely nothing, but I don't see why this needs to be done outside of > the package management system. OK, people are arguing chalk and cheese at this point, and starting to get hostile... chill :-) Adam has a very valid point that *.pyo and *.pyc files could be included inside the deb, instead of compiled and removed by the pre/postinst scripts. Sean is assuming that compiling and removing them in pre/postinst scripts is the only/proper way to do it because that's the way that it has always been done. The current Python policy does not explicitly mention the pre/postinst compilation/removal anywhere except in the special case of supporting multiple versions _because_ of the added complexities of doing this for multiple versions. When it was written, it was generally assumed that even single version python modules would use pre/posinst complilation/removal because I had never heard of anyone doing it any other way. Perhaps this needs to be clarified in the policy document... Ignoring the current policy for a minute, Sean's idea of including the pyc and pyo files in the deb does have some merit, but also some drawbacks. The main benefit is the pyc and pyo files become managed by dpkg. This means installation/removal is handled automaticly, and things like debsums and cruft can check that they have not been compromised. The biggest drawback is suddenly your debs get larger, because they include redundant pyc and pyo files, which can be autogenerated from py's. It is also possible for the py/pyc/pyo files to get out of sync if a mistake is made during building the package. It also is different from current standard practice. My gut feeling is that including the pyc/pyo files in the deb is a bad idea, mainly because I dislike redundancy and want my debs as small as possible. It would be nice to have them "registered" with dpkg somehow. It would be good if dpkg supported registering files "not included with, but created by" debs. There are many other packages besides Python that could benefit from this feature. -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
