Op vr, 17-02-2006 te 23:22 +0100, schreef Martin v. Löwis:
That, in turn, is because nobody is so short of disk space that
you really *have* to share /usr/share across architectures,
I can see diskless thin clients that boot from flash memory doing things
like that? (E.g. having documentation
Jan Claeys wrote:
That, in turn, is because nobody is so short of disk space that
you really *have* to share /usr/share across architectures,
I can see diskless thin clients that boot from flash memory doing things
like that? (E.g. having documentation and header files and other
Guido == Guido van Rossum [EMAIL PROTECTED] writes:
Guido On 2/16/06, Stephen J. Turnbull [EMAIL PROTECTED] wrote:
/usr/share often is on a different mount; that's the whole
rationale for /usr/share.
Guido I don't think I've worked at a place where something like
Guido
Bob == Bob Ippolito [EMAIL PROTECTED] writes:
Bob Huh? What does that have to do with anything? I've never
Bob seen a system where /usr/include, /usr/lib, /usr/bin,
Bob etc. are not all on the same mount. It's not really any
Bob different with OS X either.
/usr/share often is
Op wo, 15-02-2006 te 11:23 -0800, schreef Bob Ippolito:
On Feb 15, 2006, at 4:49 AM, Jan Claeys wrote:
Op wo, 15-02-2006 te 14:00 +1300, schreef Greg Ewing:
I'm disappointed that the various Linux distributions
still don't seem to have caught onto the very simple
idea of *not*
On 2/16/06, Stephen J. Turnbull [EMAIL PROTECTED] wrote:
/usr/share often is on a different mount; that's the whole rationale
for /usr/share.
I don't think I've worked at a place where something like that was
done for at least 10 years. Isn't this argument outdated?
--
--Guido van Rossum (home
Guido van Rossum wrote:
On 2/16/06, Stephen J. Turnbull [EMAIL PROTECTED] wrote:
/usr/share often is on a different mount; that's the whole rationale
for /usr/share.
I don't think I've worked at a place where something like that was
done for at least 10 years. Isn't this argument
On 2/17/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On 2/16/06, Stephen J. Turnbull [EMAIL PROTECTED] wrote:
/usr/share often is on a different mount; that's the whole rationale
for /usr/share.
I don't think I've worked at a place where something like that was
On Fri, 17 Feb 2006 14:58:34 -0800, Guido van Rossum [EMAIL PROTECTED]
wrote:
On 2/17/06, Martin v. L=F6wis [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On 2/16/06, Stephen J. Turnbull [EMAIL PROTECTED] wrote:
/usr/share often is on a different mount; that's the whole rationale
for
Bob Ippolito wrote:
** The exception is scripts. Scripts go wherever --install-scripts=
point to, and AFAIK there is no means to ensure that the scripts from
one egg do not interfere with the scripts for another egg or anything
else on the PATH. I'm also not sure what the
Op wo, 15-02-2006 te 14:00 +1300, schreef Greg Ewing:
I'm disappointed that the various Linux distributions
still don't seem to have caught onto the very simple
idea of *not* scattering files all over the place when
installing something.
MacOSX seems to be the only system so far that has
[Bob Ippolito wrote]
...
/Library/Frameworks/Python.framework/...
/Applications/MacPython-2.4/... # just MacPython does this
ActivePython doesn't install app bundles for IDLE or anything?
It does, but puts them under here instead:
On Feb 15, 2006, at 4:49 AM, Jan Claeys wrote:
Op wo, 15-02-2006 te 14:00 +1300, schreef Greg Ewing:
I'm disappointed that the various Linux distributions
still don't seem to have caught onto the very simple
idea of *not* scattering files all over the place when
installing something.
[Greg Ewing wrote]
It's not perfect, but it's still a lot better than the
situation on any other unix I've seen so far.
Better than Unix, sure. But you *can* (and ActivePython does do) install
everything under:
/opt/$app_name/...
open DMG, don't run the app from here, drag it to your
On 2/13/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
I'm actually opposed to bdist_egg, from a conceptual point of view.
I think it is wrong if Python creates its own packaging format
(just as it was wrong that Java created jar files - but they are
without deployment procedures even today).
I
(Disclaimer: I'm not currently promoting the addition of bdist_egg or any
egg-specific features for the 2.5 timeframe, but neither am I
opposed. This message is just to clarify a few points and questions under
discussion, not to advocate a particular outcome. If you read this and
think you
On Tue, Feb 14, 2006 at 11:16:32AM -0800, Guido van Rossum wrote:
Well, just like Java, if you have pure Python code, why should a
developer have to duplicate the busy-work of creating distributions
for different platforms? (Especially since there are so many different
target platforms --
Guido van Rossum [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
In private email, Phillip Eby suggested to add these things to the
2.5. standard library:
bdist_deb, bdist_msi, and friends
He explained them as follows:
bdist_deb makes .deb files (packages for Debian-based
On Feb 14, 2006, at 2:05 PM, Joe Smith wrote:
Guido van Rossum [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
In private email, Phillip Eby suggested to add these things to the
2.5. standard library:
bdist_deb, bdist_msi, and friends
He explained them as follows:
On Tue, Feb 14, 2006 at 05:05:08PM -0500, Joe Smith wrote:
I don't like the idea of bdist_deb very much.
The idea behind the debian packaging system is that unlike with RPM and
Windows, package management should be clean.
The idea behind RPM is also that package management should be clean.
At 03:14 PM 2/14/2006 -0800, Bob Ippolito wrote:
I'm also not sure what the uninstallation story
with scripts is.
The scripts have enough breadcrumbs in them that you can figure out what
egg they go with. More precisely, an egg contains enough information for
you to search PATH for its scripts
Thomas Wouters wrote:
Actually, that's where distutils and bdist_* comes in. Mr. Random Developer
writes a regular distutils setup.py, and I can install the latest,
not-quite-in-apt version by doing 'setup.py bdist_deb' and installing the
resulting .deb.
Why not just do 'setup.py install'
On Wed, Feb 15, 2006 at 01:51:03PM +1300, Greg Ewing wrote:
Thomas Wouters wrote:
Actually, that's where distutils and bdist_* comes in. Mr. Random Developer
writes a regular distutils setup.py, and I can install the latest,
not-quite-in-apt version by doing 'setup.py bdist_deb' and
Joe Smith wrote:
Windows and RPM are known for major dependency problems, letting packages
damage each other, having packages that do not uninstall cleanly (i.e.
packages that leave junk all over the place) and generally messing the sytem
up quite baddly over time, so that the OS is
On Feb 14, 2006, at 5:00 PM, Greg Ewing wrote:
Joe Smith wrote:
Windows and RPM are known for major dependency problems, letting
packages
damage each other, having packages that do not uninstall cleanly
(i.e.
packages that leave junk all over the place) and generally messing
the
On Wed, Feb 15, 2006 at 02:00:21PM +1300, Greg Ewing wrote:
Joe Smith wrote:
Windows and RPM are known for major dependency problems, letting packages
damage each other, having packages that do not uninstall cleanly (i.e.
packages that leave junk all over the place) and generally
On Feb 14, 2006, at 5:22 PM, Trent Mick wrote:
[Greg Ewing wrote]
MacOSX seems to be the only system so far that has got
this right -- organising the system so that everything
related to a given application or library can be kept
under a single directory, clearly labelled with a
version
Trent Mick wrote:
ActivePython and MacPython have to install stuff to:
/usr/local/bin/...
/Library/Frameworks/Python.framework/...
/Applications/MacPython-2.4/... # just MacPython does this
It's not perfect, but it's still a lot better than the
situation on any other unix I've
Thomas Wouters wrote:
Well, as an end user, I honestly don't care.
As a programmer, I also don't care.
Perhaps I've been burned once too often by someone's
oh-so-clever installer script screwing up and leaving
me to wade through an impenetrable pile of makefiles,
shell scripts and m4 macros
In private email, Phillip Eby suggested to add these things to the
2.5. standard library:
bdist_deb, bdist_msi, and friends
He explained them as follows:
bdist_deb makes .deb files (packages for Debian-based Linux distros, like
Ubuntu). bdist_msi makes .msi installers for Windows (it's by
On Mon, Feb 13, 2006 at 04:04:26PM -0800, Guido van Rossum wrote:
In private email, Phillip Eby suggested to add these things to the
2.5. standard library:
bdist_deb, bdist_msi, and friends
FWIW, I've been using a patched distutils with bdist_deb, and it's worked
fine for the most part. The
31 matches
Mail list logo
