[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 abo@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------



Reply to: