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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > > --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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Mark Williamson
2005-Feb-06 18:28 UTC
Re: [Xen-devel] debian python-install.patch (3 of 5)
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Mark Williamson
2005-Feb-06 18:49 UTC
Re: [Xen-devel] debian python-install.patch (3 of 5)
> > 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Christian Limpach
2005-Feb-06 23:47 UTC
Re: [Xen-devel] debian python-install.patch (3 of 5)
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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_id396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel