RE: debian python-install.patch (3 of 5)

RE: debian python-install.patch (3 of 5)

[Ian Pratt]

> > Do you use the dist directory for your package build? If 
> not, why do you
> > care?
> 
> I don't use the dist target, but I do use the install target, 
> and set DESTDIR
> to debian/install.

I'd have no problem with the 'install' target doing something different
from 'dist'.

> > If you do, maybe we'll need some flag to change the 
> behaviour. This will
> > all be rather more obvious if we can get the debian package 
> build runes
> > checked into the xen repo.
> 
> Well, I need to figure out how that can happen.  I may have 
> to maintain some
> changes for debian, that make no sense upstream(for instance, 
> disabling the
> html doc generation, because latex2html is non-free), and 
> this is difficult
> when everything is in one repo.

The latex2html issue is easy -- we should check to see whether the
latex2html binary exists, otherwise skip it.

> Besides, if the debian bits are added to bitkeeper, then I 
> can't ever check
> things in to them(I'm not allowed to use bitkeeper, because I work on
> dpkg-source).

Eevn if you don't always directly use the debian bits that are in the BK
repo, I'd like to have them there, and kept fairly up to date.
Presumably they're not going to change much once they're 'done'?

Ian


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

RE: debian python-install.patch (3 of 5)

[Adam Heath]

On Sun, 6 Feb 2005, Ian Pratt wrote:

> > I don't use the dist target, but I do use the install target,
> > and set DESTDIR
> > to debian/install.
>
> I'd have no problem with the 'install' target doing something different
> from 'dist'.

That's different from all other build systems I have worked with, and will
cause confusion with random people looking at the source.

> > Well, I need to figure out how that can happen.  I may have
> > to maintain some
> > changes for debian, that make no sense upstream(for instance,
> > disabling the
> > html doc generation, because latex2html is non-free), and
> > this is difficult
> > when everything is in one repo.
>
> The latex2html issue is easy -- we should check to see whether the
> latex2html binary exists, otherwise skip it.

No, that's not correct.

Even if the latex2html binary exists, you can't call it.  non-free things
could be installed on the build host, but as long as you don't call them, you
don't depend on them.

There should be some kind of configure-like setup.

> > Besides, if the debian bits are added to bitkeeper, then I
> > can't ever check
> > things in to them(I'm not allowed to use bitkeeper, because I work on
> > dpkg-source).
>
> Eevn if you don't always directly use the debian bits that are in the BK
> repo, I'd like to have them there, and kept fairly up to date.
> Presumably they're not going to change much once they're 'done'?

debian/changelog changes with each upload(version, changelog entry, and
timestamp).

Don't get me wrong, I am not trying to keep the debian stuff to myself.  It's
just difficult to integrate with upstream(any upstream, not just xen).


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: debian python-install.patch (3 of 5)

[Mark Williamson]

> > The latex2html issue is easy -- we should check to see whether the
> > latex2html binary exists, otherwise skip it.
>
> No, that's not correct.
>
> Even if the latex2html binary exists, you can't call it.  non-free things
> could be installed on the build host, but as long as you don't call them,
> you don't depend on them.
>
> There should be some kind of configure-like setup.

I'm sorry, I don't quite see the distinction here.  I'm not particularly 
familiar with Debian policy - does being able to take advantage of non-free 
software that happens to be present constitute a dependency?

> debian/changelog changes with each upload(version, changelog entry, and
> timestamp).
>
> Don't get me wrong, I am not trying to keep the debian stuff to myself. 
> It's just difficult to integrate with upstream(any upstream, not just xen).

OK, makes sense.  If it's going to cause trouble, perhaps you could maintain 
the Debian build system for the "real" packages separately but supply 
snapshots to check in every so often?  I agree it's not really ideal.

Cheers,
Mark


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: debian python-install.patch (3 of 5)

[Adam Heath]

On Sun, 6 Feb 2005, Mark Williamson wrote:

> > No, that's not correct.
> >
> > Even if the latex2html binary exists, you can't call it.  non-free things
> > could be installed on the build host, but as long as you don't call them,
> > you don't depend on them.
> >
> > There should be some kind of configure-like setup.
>
> I'm sorry, I don't quite see the distinction here.  I'm not particularly
> familiar with Debian policy - does being able to take advantage of non-free
> software that happens to be present constitute a dependency?

It must be possible to build an empty chroot, install only the listed build
depends, and get exactly the same set of debs, as compared to building on a
heavily loaded development system(that may just happen to have things
installed that, for whatever reason, shouldn't be used).

This is all about automation.  Being able to reproduce the final output,
exactly as needed.

If random things are installed, and change the features enabled in some debs,
then this requirement is broken.

> > debian/changelog changes with each upload(version, changelog entry, and
> > timestamp).
> >
> > Don't get me wrong, I am not trying to keep the debian stuff to myself.
> > It's just difficult to integrate with upstream(any upstream, not just xen).
>
> OK, makes sense.  If it's going to cause trouble, perhaps you could maintain
> the Debian build system for the "real" packages separately but supply
> snapshots to check in every so often?  I agree it's not really ideal.

I've never really had such an active upstream, so willing to make things
easier.  koth was closest, but they weren't interested in debian/*, just the
changes I'd make to their source.



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: debian python-install.patch (3 of 5)

[Christian Limpach]

On Sun, 6 Feb 2005 18:49:54 +0000, Mark Williamson <maw48@cl.cam.ac.uk> wrote:
> > debian/changelog changes with each upload(version, changelog entry, and
> > timestamp).
> >
> > Don't get me wrong, I am not trying to keep the debian stuff to myself.
> > It's just difficult to integrate with upstream(any upstream, not just xen).
> 
> OK, makes sense.  If it's going to cause trouble, perhaps you could maintain
> the Debian build system for the "real" packages separately but supply
> snapshots to check in every so often?  I agree it's not really ideal.

I really don't see the point of including the debian build support in
the bk repository.  It's just as easy for anybody who wants to build
updated packages to apt-get source the debian build infrastructure and
then make that use an updated source tarball.  Maybe the debian build
support could have an option to point it at a local bk tree instead of
using a source tarball.

     christian


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

RE: debian python-install.patch (3 of 5)

[Ian Pratt]

I think the main point is that we're only too happy to put stuff into
Xen to make it easier to build rpm/deb's etc. I'd like to have this
stuff checked into our tree to minimize the downstream diffs -- if it's
in the tree then we're more likely to remember to bare the requirements
in mind with future changes. It also gives us (as in xen-devel) the
opportunity to see how Xen is being packaged and provide
comments/feedback, and perhaps encourage some kind of uniformity across
the different vendor packages.

However, we still need to make sure that all the build options that are
convenient for developers are still available, ideally as the default.

Ian

> -----Original Message-----
> From: Adam Heath [mailto:doogie@brainfood.com] 
> Sent: 07 February 2005 18:50
> To: Brian Wolfe
> Cc: Ian Pratt; Xen Devel Mailing List; 
> Keir.Fraser@cl.cam.ac.uk; ian.pratt@cl.cam.ac.uk
> Subject: RE: [Xen-devel] debian python-install.patch (3 of 5)
> 
> On Mon, 7 Feb 2005, Brian Wolfe wrote:
> 
> > On Sun, 2005-02-06 at 18:00 +0000, Ian Pratt wrote:
> > >  > > >  --home causes python's distutils to install into
> > > > > > /usr/lib/python/, while
> > > > > >  --root causes it to install into
> > > > > > /usr/lib/python$ver/site-packages, which
> > > > > >  is the more correct location.
> > > > Er, in all packages I have ever used, make dist has given me
> > > > a tree(which is
> > > > normally placed into a tar by upstream, and 'dist'ributed,
> > > > hence the name),
> > > > that can then be optionally overlayed ontop an already
> > > > installed system.
> > >
> > > Yes, but its quite usual for bpeople to install Xen on a different
> > > system to which is was built (e.g. our binary install tar file).
> > > Installing into /usr/lib/python/ means that it'll be 
> found on the module
> > > search path, whereas /usr/lib/python$ver/site-packages 
> will only work if
> > > the version is the same.
> >
> > Mind please that I have no empirical proof, just personal 
> experience and
> > opinions/preferences expressed to me by admins I know.
> >
> > I would have to disagree here. If Xen is to be taken seriously in a
> > commercial environment, then it's going to have to be available as a
> > dist binary from either redhat, suse, debina, or another 
> top level linux
> > distro IMHO.
> >
> > Having to compile things for every machine tends to turn 
> potential users
> > off that aren't programmers or gentoo/*bsd afficianados from my
> > experience.
> >
> > Heck, this is why I stated packaging 1.3 in the first place. I just
> > couldn't deal with deploying by hand every couple of days. I really
> > needed it to be automatic as possible.
> 
> You don't actually come out for or against any variation. :|
> 


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

RE: debian python-install.patch (3 of 5)

[Adam Heath]

On Mon, 7 Feb 2005, Ian Pratt wrote:

> I think the main point is that we're only too happy to put stuff into
> Xen to make it easier to build rpm/deb's etc. I'd like to have this
> stuff checked into our tree to minimize the downstream diffs -- if it's
> in the tree then we're more likely to remember to bare the requirements
> in mind with future changes. It also gives us (as in xen-devel) the
> opportunity to see how Xen is being packaged and provide
> comments/feedback, and perhaps encourage some kind of uniformity across
> the different vendor packages.

I feel the same.  That's why I am sending these patches upstream.

Not all need to be accepted.  But if they cause discussions, and a better way
can be found, then everyone benefits.

Have you guys seen any changes from any redhat/gentoo/slackware/suse/etc
packagers?

> However, we still need to make sure that all the build options that are
> convenient for developers are still available, ideally as the default.

Yes, it must be easy for the developers.  They compile and test it way more
than any user will.

However, on that note, there will always be more users than there are
developers, so making things easy for them is worthwhile as well.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

RE: debian python-install.patch (3 of 5)

[Ian Pratt]

 > > >  --home causes python's distutils to install into
> > > /usr/lib/python/, while
> > >  --root causes it to install into
> > > /usr/lib/python$ver/site-packages, which
> > >  is the more correct location.
> Er, in all packages I have ever used, make dist has given me 
> a tree(which is
> normally placed into a tar by upstream, and 'dist'ributed, 
> hence the name),
> that can then be optionally overlayed ontop an already 
> installed system.

Yes, but its quite usual for bpeople to install Xen on a different
system to which is was built (e.g. our binary install tar file).
Installing into /usr/lib/python/ means that it'll be found on the module
search path, whereas /usr/lib/python$ver/site-packages will only work if
the version is the same.

Do you use the dist directory for your package build? If not, why do you
care?
 
If you do, maybe we'll need some flag to change the behaviour. This will
all be rather more obvious if we can get the debian package build runes
checked into the xen repo.

Thanks,
Ian 


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

RE: debian python-install.patch (3 of 5)

[Adam Heath]

On Sun, 6 Feb 2005, Ian Pratt wrote:

>  > > >  --home causes python's distutils to install into
> > > > /usr/lib/python/, while
> > > >  --root causes it to install into
> > > > /usr/lib/python$ver/site-packages, which
> > > >  is the more correct location.
> > Er, in all packages I have ever used, make dist has given me
> > a tree(which is
> > normally placed into a tar by upstream, and 'dist'ributed,
> > hence the name),
> > that can then be optionally overlayed ontop an already
> > installed system.
>
> Yes, but its quite usual for bpeople to install Xen on a different
> system to which is was built (e.g. our binary install tar file).
> Installing into /usr/lib/python/ means that it'll be found on the module
> search path, whereas /usr/lib/python$ver/site-packages will only work if
> the version is the same.
>
> Do you use the dist directory for your package build? If not, why do you
> care?

I don't use the dist target, but I do use the install target, and set DESTDIR
to debian/install.

> If you do, maybe we'll need some flag to change the behaviour. This will
> all be rather more obvious if we can get the debian package build runes
> checked into the xen repo.

Well, I need to figure out how that can happen.  I may have to maintain some
changes for debian, that make no sense upstream(for instance, disabling the
html doc generation, because latex2html is non-free), and this is difficult
when everything is in one repo.

Besides, if the debian bits are added to bitkeeper, then I can't ever check
things in to them(I'm not allowed to use bitkeeper, because I work on
dpkg-source).



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: debian python-install.patch (3 of 5)

[Mark Williamson]

> Besides, if the debian bits are added to bitkeeper, then I can't ever check
> things in to them(I'm not allowed to use bitkeeper, because I work on
> dpkg-source).

I think we'd find it useful ourselves to have .deb build targets in the tree, 
if you're willing.  Can't you just send patches to update it as you have been 
doing?

Cheers,
Mark


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: debian python-install.patch (3 of 5)

[Adam Heath]

On Sun, 6 Feb 2005, Mark Williamson wrote:

> > Besides, if the debian bits are added to bitkeeper, then I can't ever check
> > things in to them(I'm not allowed to use bitkeeper, because I work on
> > dpkg-source).
>
> I think we'd find it useful ourselves to have .deb build targets in the tree,
> if you're willing.  Can't you just send patches to update it as you have been
> doing?

I could, but it'd be difficult.  The various changes needed to make policy
compliant debs that don't make sense upstream, would mean either that debian/*
would be different in bitkeeper as compared to debian.org, or that what was in
bitkeeper debian/* wouldn't build, as they'd attempt to do things that
upstream doesn't have applied.



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

RE: debian python-install.patch (3 of 5)

[Adam Heath]

On Sun, 6 Feb 2005, Adam Heath wrote:

> Besides, if the debian bits are added to bitkeeper, then I can't ever check
> things in to them(I'm not allowed to use bitkeeper, because I work on
> dpkg-source).

The xen source package for debian is located here:

http://people.debian.org/~doogie/packages/

So, you can look if you want.

xen_2.0.4.orig.tar.gz is identical to xen-2.0.4.tar.gz from your site.


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

RE: debian python-install.patch (3 of 5)

[Brian Wolfe]

On Sun, 2005-02-06 at 18:00 +0000, Ian Pratt wrote:
>  > > >  --home causes python's distutils to install into
> > > > /usr/lib/python/, while
> > > >  --root causes it to install into
> > > > /usr/lib/python$ver/site-packages, which
> > > >  is the more correct location.
> > Er, in all packages I have ever used, make dist has given me 
> > a tree(which is
> > normally placed into a tar by upstream, and 'dist'ributed, 
> > hence the name),
> > that can then be optionally overlayed ontop an already 
> > installed system.
> 
> Yes, but its quite usual for bpeople to install Xen on a different
> system to which is was built (e.g. our binary install tar file).
> Installing into /usr/lib/python/ means that it'll be found on the module
> search path, whereas /usr/lib/python$ver/site-packages will only work if
> the version is the same.

Mind please that I have no empirical proof, just personal experience and
opinions/preferences expressed to me by admins I know.

I would have to disagree here. If Xen is to be taken seriously in a
commercial environment, then it's going to have to be available as a
dist binary from either redhat, suse, debina, or another top level linux
distro IMHO. 

Having to compile things for every machine tends to turn potential users
off that aren't programmers or gentoo/*bsd afficianados from my
experience.

Heck, this is why I stated packaging 1.3 in the first place. I just
couldn't deal with deploying by hand every couple of days. I really
needed it to be automatic as possible.

> 
> Do you use the dist directory for your package build? If not, why do you
> care?
>  
> If you do, maybe we'll need some flag to change the behaviour. This will
> all be rather more obvious if we can get the debian package build runes
> checked into the xen repo.
> 
> Thanks,
> Ian 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

RE: debian python-install.patch (3 of 5)

[Adam Heath]

On Mon, 7 Feb 2005, Brian Wolfe wrote:

> On Sun, 2005-02-06 at 18:00 +0000, Ian Pratt wrote:
> >  > > >  --home causes python's distutils to install into
> > > > > /usr/lib/python/, while
> > > > >  --root causes it to install into
> > > > > /usr/lib/python$ver/site-packages, which
> > > > >  is the more correct location.
> > > Er, in all packages I have ever used, make dist has given me
> > > a tree(which is
> > > normally placed into a tar by upstream, and 'dist'ributed,
> > > hence the name),
> > > that can then be optionally overlayed ontop an already
> > > installed system.
> >
> > Yes, but its quite usual for bpeople to install Xen on a different
> > system to which is was built (e.g. our binary install tar file).
> > Installing into /usr/lib/python/ means that it'll be found on the module
> > search path, whereas /usr/lib/python$ver/site-packages will only work if
> > the version is the same.
>
> Mind please that I have no empirical proof, just personal experience and
> opinions/preferences expressed to me by admins I know.
>
> I would have to disagree here. If Xen is to be taken seriously in a
> commercial environment, then it's going to have to be available as a
> dist binary from either redhat, suse, debina, or another top level linux
> distro IMHO.
>
> Having to compile things for every machine tends to turn potential users
> off that aren't programmers or gentoo/*bsd afficianados from my
> experience.
>
> Heck, this is why I stated packaging 1.3 in the first place. I just
> couldn't deal with deploying by hand every couple of days. I really
> needed it to be automatic as possible.

You don't actually come out for or against any variation. :|


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

RE: debian python-install.patch (3 of 5)

[Rik van Riel]

On Mon, 7 Feb 2005, Brian Wolfe wrote:

> I would have to disagree here. If Xen is to be taken seriously in a 
> commercial environment, then it's going to have to be available as a 
> dist binary from either redhat, suse, debina, or another top level linux 
> distro IMHO.

But, it is.  Xen is available in Fedora Rawhide, and I
believe that SuSE developers are also working on packages.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

RE: debian python-install.patch (3 of 5)

[Ian Pratt]

 
> Name: python-install.patch
> Description: Use --root instead of --home
>  --home causes python's distutils to install into 
> /usr/lib/python/, while
>  --root causes it to install into 
> /usr/lib/python$ver/site-packages, which
>  is the more correct location.

This was deliberately changed a few weeks back. 

http://xen.bkbits.net:8080/xen-2.0-testing.bk/diffs/tools/python/Makefil
e@1.10?nav=index.html|src/.|src/tools|src/tools/python|hist/tools/python
/Makefile

When doing a make dist, dist/install/usr/lib/python is probably the best
location to put the packages.

When doing a reall install, /usr/lib/python$ver/site-packages may well
be the right location.

The build system has been messed around with so much I'm not sure its
still possible to tell the difference between the two cases.

Can we at least get agreement on the behaviour we want?

Ian

> Signed-off-by: Adam Heath <doogie@brainfood.com>
> DiffStat:
>  tools/python/Makefile |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> --- xen-2.0.4.orig/tools/python/Makefile
> +++ xen-2.0.4/tools/python/Makefile
> @@ -5,8 +5,8 @@
>  all:
>  	CFLAGS="$(CFLAGS)" python setup.py build
>  
> -install: all
> -	CFLAGS="$(CFLAGS)" python setup.py install 
> --home="$(DESTDIR)/usr"
> +install: build
> +	CFLAGS="$(CFLAGS)" python setup.py install --root="$(DESTDIR)"
>  
>  clean:
>  	rm -rf build *.pyc *.pyo *.o *.a *~


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

RE: debian python-install.patch (3 of 5)

[Adam Heath]

On Sat, 5 Feb 2005, Ian Pratt wrote:

>
> > Name: python-install.patch
> > Description: Use --root instead of --home
> >  --home causes python's distutils to install into
> > /usr/lib/python/, while
> >  --root causes it to install into
> > /usr/lib/python$ver/site-packages, which
> >  is the more correct location.
>
> This was deliberately changed a few weeks back.
>
> http://xen.bkbits.net:8080/xen-2.0-testing.bk/diffs/tools/python/Makefil
> e@1.10?nav=index.html|src/.|src/tools|src/tools/python|hist/tools/python
> /Makefile
>
> When doing a make dist, dist/install/usr/lib/python is probably the best
> location to put the packages.
>
> When doing a reall install, /usr/lib/python$ver/site-packages may well
> be the right location.

Er, in all packages I have ever used, make dist has given me a tree(which is
normally placed into a tar by upstream, and 'dist'ributed, hence the name),
that can then be optionally overlayed ontop an already installed system.

This implies that the directory layout underneath dist/install needs to be the
same as it would be installing to / to begin with.

> The build system has been messed around with so much I'm not sure its
> still possible to tell the difference between the two cases.
>
> Can we at least get agreement on the behaviour we want?

I'm trying to make xen behave like everything else I've seen in my packaging
experience with debian.  Consistency is good, no?  It lowers the barrier for
other people to understand what is going on. Ultimately, it let's more people
play both with the final product, and with the source itself.



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

debian python-install.patch (3 of 5)

[Adam Heath]

Name: python-install.patch
Description: Use --root instead of --home
 --home causes python's distutils to install into /usr/lib/python/, while
 --root causes it to install into /usr/lib/python$ver/site-packages, which
 is the more correct location.
Signed-off-by: Adam Heath <doogie@brainfood.com>
DiffStat:
 tools/python/Makefile |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

--- xen-2.0.4.orig/tools/python/Makefile
+++ xen-2.0.4/tools/python/Makefile
@@ -5,8 +5,8 @@
 all:
 	CFLAGS="$(CFLAGS)" python setup.py build
 
-install: all
-	CFLAGS="$(CFLAGS)" python setup.py install --home="$(DESTDIR)/usr"
+install: build
+	CFLAGS="$(CFLAGS)" python setup.py install --root="$(DESTDIR)"
 
 clean:
 	rm -rf build *.pyc *.pyo *.o *.a *~



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl