Targeting RPM and Debian from a Debian box?
Christian Convey
both .deb and .rpm releases of my software.
Is this something people normally do from the same Debian workstation,
or do they typically fire up a RedHat system to do their .rpm
creation, and use a Debian workstation to do their .deb creation?
Thanks,
Christian
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Russ Allbery
> My development workstation is running Debian, and I'd like to produce
> both .deb and .rpm releases of my software.
> Is this something people normally do from the same Debian workstation,
> or do they typically fire up a RedHat system to do their .rpm creation,
> and use a Debian workstation to do their .deb creation?
You'll have to use the appropriate OS to build packages for that OS.
Debian requires this as well in order to get things like shared library
dependencies right, to satisfy Build-Depends, and so forth. It makes
sense that RPM has the same issues.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bernd Zeimetz
> My development workstation is running Debian, and I'd like to produce
> both .deb and .rpm releases of my software.
depending on your software producing packages for Redhat, SuSE or any
other rpm based distributions on a Debian box is not what you want to do
as you want to use their specific library versions to build your package
properly. If you're only packaging some architecture independent stuff,
it probably doesn't matter at all - you would want to test your package
on the target distribution, though.
Cheers,
Bernd
--
Bernd Zeimetz
<be...@bzed.de> <http://bzed.de/>
Christian Convey
> Christian Convey <christia...@gmail.com> writes:
>
> > My development workstation is running Debian, and I'd like to produce
> > both .deb and .rpm releases of my software.
>
> > Is this something people normally do from the same Debian workstation,
> > or do they typically fire up a RedHat system to do their .rpm creation,
> > and use a Debian workstation to do their .deb creation?
>
> You'll have to use the appropriate OS to build packages for that OS.
> Debian requires this as well in order to get things like shared library
> dependencies right, to satisfy Build-Depends, and so forth. It makes
> sense that RPM has the same issues.
>
> --
> Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
>
Thanks everyone.
Luis Matos
> Hi,
>
> > My development workstation is running Debian, and I'd like to produce
> > both .deb and .rpm releases of my software.
them.
Peter Makholm
> Is this something people normally do from the same Debian workstation,
> or do they typically fire up a RedHat system to do their .rpm
> creation, and use a Debian workstation to do their .deb creation?
Never done it myself but I would at least built the rpm in a chroot or
vserver with the target distribution installed.
//Makholm
Ivan Jager
> Christian Convey <christia...@gmail.com> writes:
>
>> My development workstation is running Debian, and I'd like to produce
>> both .deb and .rpm releases of my software.
>
>> Is this something people normally do from the same Debian workstation,
>> or do they typically fire up a RedHat system to do their .rpm creation,
>> and use a Debian workstation to do their .deb creation?
>
> You'll have to use the appropriate OS to build packages for that OS.
> Debian requires this as well in order to get things like shared library
> dependencies right, to satisfy Build-Depends, and so forth. It makes
> sense that RPM has the same issues.
I don't build RPMs any more, but you should be able to build them just
fine inside a chroot. Look at the schroot package if you want to do it as
a normal user.
You will still want an install of each distro you want to build/test
packages for, although some things built for one distro may work fine on
another.
Ivan
Bernd Zeimetz
> Never done it myself but I would at least built the rpm in a chroot or
> vserver with the target distribution installed.
vserver is a good hint here, definitely my favourite way to install
diferent distributions/versions/... on one machine, and way less
ressource intensive than xen & co.
--
Bernd Zeimetz
<be...@bzed.de> <http://bzed.de/>
Hamish Moffatt
> "Christian Convey" <christia...@gmail.com> writes:
>
> > Is this something people normally do from the same Debian workstation,
> > or do they typically fire up a RedHat system to do their .rpm
> > creation, and use a Debian workstation to do their .deb creation?
>
> Never done it myself but I would at least built the rpm in a chroot or
> vserver with the target distribution installed.
It looks like rpmstrap could build you a suitable chroot (like
debootstap for Debian), but from the description it appears to be
somewhat outdated (eg Fedora Core 2).
Hamish
--
Hamish Moffatt VK3SB <ham...@debian.org> <ham...@cloud.net.au>
Roberto C. Sánchez
> On Fri, Jul 06, 2007 at 05:06:56PM +0000, Peter Makholm wrote:
> > "Christian Convey" <christia...@gmail.com> writes:
> >
> > > Is this something people normally do from the same Debian workstation,
> > > or do they typically fire up a RedHat system to do their .rpm
> > > creation, and use a Debian workstation to do their .deb creation?
> >
> > Never done it myself but I would at least built the rpm in a chroot or
> > vserver with the target distribution installed.
>
> It looks like rpmstrap could build you a suitable chroot (like
> debootstap for Debian), but from the description it appears to be
> somewhat outdated (eg Fedora Core 2).
>
being fairly old at this point), it just doesn't work.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
Holger Levsen
On Saturday 07 July 2007 08:30, Hamish Moffatt wrote:
> It looks like rpmstrap could build you a suitable chroot (like
> debootstap for Debian), but from the description it appears to be
> somewhat outdated (eg Fedora Core 2).
mock worked for me to setup Fedora Core 6, haven#t tried 7 yet.
O etch it hits one bug in rpm, so you need to mkdir /var/lib/rpm outside the
chroot. Doh! See the BTS for more info.
regards,
Holger
Loïc Minier
> O etch it hits one bug in rpm, so you need to mkdir /var/lib/rpm outside the
> chroot. Doh! See the BTS for more info.
Right; in fact, it's presumably both a feature and a bug of our RPM
packages: "RPM Transaction Sets" don't work properly when rpmlock_path
isn't writable because they need to take the lock using this file,
however _rpmlock_path defaults to dbpath, and the Debian RPM package
doesn't ship a /var/lib/rpm to avoid people installing *.rpm files
along their dpkg managed system.
So one way is indeed to create a /var/lib/rpm, another way is to set
(for example via /etc/rpm/macros.mach):
%_rpmlock_path /var/lib/rpm-lock/__db.000
this still gives the protection that RPM won't allow to install
packages.
One could wonder why mach/mock don't workaround / override these
values -- especially to use pathnames in the chroot -- but the problem
is that the host's yum doesn't offer anyway to set RPM macros and RPM's
dbpath when setting --root isn't relative to the root. :-/
--
Loďc Minier
Brett Parker
> Sex, 2007-07-06 ??s 18:47 +0200, Bernd Zeimetz escreveu:
> > Hi,
> >
> > > My development workstation is running Debian, and I'd like to produce
> > > both .deb and .rpm releases of my software.
> you can easily use virtual machines like xen and qemu to build and test
> them.
You don't even have to go that far... I build rpm packages in a CentOS 5
chroot on a Debian Etch box. It makes it so much more fun :)
(Never did get mach or the other rpm tools to work though - so it's
sortof bolted together with a bunch of shell scripts and the chroot was
built using a bash script I knocked up a while back...)
Cheers,
--
Brett Parker
Hector Oron
Adam Borowski
> >> > My development workstation is running Debian, and I'd like to produce
> >> > both .deb and .rpm releases of my software.
>
> Maybe using 'alien'?
This is an option only if your dependencies include hardly anything else
than libc6, and even then you should build your package against an ancient
libc. Generally, not the best idea for anything not self-contained.
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.