development packages and multilib

[Björn Persson]

I'm trying to learn how to build packages for Fedora. My first question is 
about multilib development packages.

I know that compiled libraries can be installed in both 32-bit and 64-bit 
versions at the same time, but is this required for -devel packages as well? 
That is, is it normal to compile both 32-bit and 64-bit programs on the same 
host, so that one needs both libwhatever-devel.i386 and 
libwhatever-devel.x86_64, or is it permissible for the two versions of 
libwhatever-devel to conflict with each other?

Björn Persson

[Orcan Ogetbil]

2009/4/19 Björn Persson:
>  I'm trying to learn how to build packages for Fedora. My first
> question is
>  about multilib development packages.
>
>  I know that compiled libraries can be installed in both 32-bit and 64-bit
>  versions at the same time, but is this required for -devel packages as well?
>  That is, is it normal to compile both 32-bit and 64-bit programs on the same
>  host, so that one needs both libwhatever-devel.i386 and
>  libwhatever-devel.x86_64, or is it permissible for the two versions of
>  libwhatever-devel to conflict with each other?
>
>  Björn Persson
>  
This is a dilemma we have in Fedora. I have no idea why someone would
want to keep the devel subpackages of the same package with different
archs installed.

Even adding a %doc makes these devel subpackages conflict each other.
I do wonder what is the logic laying behind.

Orcan

[Tony Breeds]

On Sun, Apr 19, 2009 at 06:43:10PM -0400, Orcan Ogetbil wrote:

>  This is a dilemma we have in Fedora. I have no idea why someone
> would
>  want to keep the devel subpackages of the same package with different
>  archs installed. 
For example.
I have a production tool that needs to run (and therfore be tested) on both 32
and 64 bit varients of my platform (say intel or powerpc).  I need both the
/usr/lib and /usr/lib64 files (and therefor the packages) installed so I can
compile and test locally.

Sure I /could/ to the testing on the target server but I don't need (nor want)
to.
 
>  Even adding a %doc makes these devel subpackages conflict each
> other.
>  I do wonder what is the logic laying behind. 
I agree this isn't an easy problem to solve and has been discussed many times
here (and I've only been here for 6 months ;P)

Yours Tony

[Callum Lerwick]

On Sun, 2009-04-19 at 18:43 -0400, Orcan Ogetbil wrote:
>  2009/4/19 Björn Persson:
>  > I'm trying to learn how to build packages for Fedora. My first question is
>  > about multilib development packages.
>  >
>  > I know that compiled libraries can be installed in both 32-bit and 64-bit
>  > versions at the same time, but is this required for -devel packages as well?
>  > That is, is it normal to compile both 32-bit and 64-bit programs on the same
>  > host, so that one needs both libwhatever-devel.i386 and
>  > libwhatever-devel.x86_64, or is it permissible for the two versions of
>  > libwhatever-devel to conflict with each other?
>  >
>  > Björn Persson
>  
>  This is a dilemma we have in Fedora. I have no idea why someone would
>  want to keep the devel subpackages of the same package with different
>  archs installed.
>  
>  Even adding a %doc makes these devel subpackages conflict each other.
>  I do wonder what is the logic laying behind. 
It's required if you want to compile both x86_64 and i386 on an x86_64
machine. I do it all the time. (-m32 flag to gcc)

[Richard W.M. Jones]

On Sun, Apr 19, 2009 at 06:43:10PM -0400, Orcan Ogetbil wrote:
>  This is a dilemma we have in Fedora. I have no idea why someone
> would
>  want to keep the devel subpackages of the same package with different
>  archs installed. 
Because one wants to compile with 'gcc -m32'.  This is very useful
when you have virtualization.

Unfortunately the more I look at multilib, the more totally broken it
seems to be.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

[Jesse Keating]

On Mon, 2009-04-20 at 09:22 +0100, Richard W.M. Jones wrote:
>  Because one wants to compile with 'gcc -m32'.  This is very
> useful
>  when you have virtualization.
>  
>  Unfortunately the more I look at multilib, the more totally broken it
>  seems to be. 
Yes, multilib is rather a disaster for this.  That's what mock is for.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Callum Lerwick]

On Mon, 2009-04-20 at 11:23 -0700, Jesse Keating wrote:
>  On Mon, 2009-04-20 at 09:22 +0100, Richard W.M. Jones wrote:
>  > Because one wants to compile with 'gcc -m32'.  This is very useful
>  > when you have virtualization.
>  > 
>  > Unfortunately the more I look at multilib, the more totally broken it
>  > seems to be.
>  
>  Yes, multilib is rather a disaster for this.  That's what mock is for. 
It works just fine. No way in hell is mock going to be acceptable for a
quick turn-around edit-compile-test cycle on a massive OpenGL app.

[Jesse Keating]

On Mon, 2009-04-20 at 13:29 -0500, Callum Lerwick wrote:
>  
>  It works just fine. No way in hell is mock going to be acceptable for a
>  quick turn-around edit-compile-test cycle on a massive OpenGL app. 
Supporting multilib creates untold number of disasters and unfixable
situations.  Its just not worth it when you can maintain a chroot (mock
or not) of the arch you wish to fiddle with.  Trying to continue to do
it in / is just insane.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Callum Lerwick]

On Mon, 2009-04-20 at 11:40 -0700, Jesse Keating wrote:
>  On Mon, 2009-04-20 at 13:29 -0500, Callum Lerwick wrote:
>  > 
>  > It works just fine. No way in hell is mock going to be acceptable for a
>  > quick turn-around edit-compile-test cycle on a massive OpenGL app.
>  
>  Supporting multilib creates untold number of disasters and unfixable
>  situations.  Its just not worth it when you can maintain a chroot (mock
>  or not) of the arch you wish to fiddle with.  Trying to continue to do
>  it in / is just insane. 
It WORKSFORME.

[Jesse Keating]

On Mon, 2009-04-20 at 13:59 -0500, Callum Lerwick wrote:
>  On Mon, 2009-04-20 at 11:40 -0700, Jesse Keating wrote:
>  > On Mon, 2009-04-20 at 13:29 -0500, Callum Lerwick wrote:
>  > > 
>  > > It works just fine. No way in hell is mock going to be acceptable for a
>  > > quick turn-around edit-compile-test cycle on a massive OpenGL app.
>  > 
>  > Supporting multilib creates untold number of disasters and unfixable
>  > situations.  Its just not worth it when you can maintain a chroot (mock
>  > or not) of the arch you wish to fiddle with.  Trying to continue to do
>  > it in / is just insane.
>  
>  It WORKSFORME. 
While that may be true, it breaks for a lot of other people.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Matthew Woehlke]

Jesse Keating wrote:
>  On Mon, 2009-04-20 at 13:29 -0500, Callum Lerwick wrote:
> > It works just fine. No way in hell is mock going to be acceptable for a
> > quick turn-around edit-compile-test cycle on a massive OpenGL app.
>  
>  Supporting multilib creates untold number of disasters and unfixable
>  situations.  Its just not worth it when you can maintain a chroot (mock
>  or not) of the arch you wish to fiddle with. 
...which means -m32 would stop working, which means my $DAYJOB would 
have to change distros on our build machines.

We rely on being able to build 32- and 64-bit binaries as part of the 
same build. How exactly is that supposed to work with mock?

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Use the --force, Luke -- Riccardo Iaconelli

[Tom Lane]

Matthew Woehlke <mw_triad(a)users.sourceforge.net&gt; writes:
>  We rely on being able to build 32- and 64-bit binaries as part of the
>
>  same build. How exactly is that supposed to work with mock? 
I wonder how you get it to work now ... you must have a very short
list of packages you depend on.

			regards, tom lane

[Callum Lerwick]

On Thu, 2009-04-23 at 17:12 -0400, Tom Lane wrote:
>  Matthew Woehlke <mw_triad(a)users.sourceforge.net&gt; writes:
>  > We rely on being able to build 32- and 64-bit binaries as part of the 
>  > same build. How exactly is that supposed to work with mock?
>  
>  I wonder how you get it to work now ... you must have a very short
>  list of packages you depend on. 
I've compiled the Second Life client this way. It has a hell of a
dependency list, and it works just fine.

[Matthew Woehlke]

Tom Lane wrote:
>  Matthew Woehlke <please@don't> writes: 
Please do not quote my e-mail address unobfuscated in message bodies.

> > We rely on being able to build 32- and 64-bit binaries as part of
> the 
> > same build. How exactly is that supposed to work with mock?
>  
>  I wonder how you get it to work now ... you must have a very short
>  list of packages you depend on. 
To be honest... glibc and ncurses :-). And occasionally a few (and I do 
mean "few", as in, less than a half dozen) others can be useful. (That 
said, I also have yet to encounter problems with multilib...)

(I also have about a dozen other non-devel multilib packages installed 
for various things.)

-- 
Matthew
Use the --force, Luke -- Riccardo Iaconelli

[Jesse Keating]

On Thu, 2009-04-23 at 15:58 -0500, Matthew Woehlke wrote:
>  ...which means -m32 would stop working, which means my $DAYJOB would
>
>  have to change distros on our build machines.
>  
>  We rely on being able to build 32- and 64-bit binaries as part of the 
>  same build. How exactly is that supposed to work with mock? 
Well in our production environment we require clean chroots be created
for every build, so we create a clean i386 chroot to build the i386
binaries, we create a clean x86_64 chroot to build the x86_64 binaries,
we create a clean ppc chroot to create the ppc binaries, I think you see
where I'm going with this.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Matthew Woehlke]

Jesse Keating wrote:
>  On Thu, 2009-04-23 at 15:58 -0500, Matthew Woehlke wrote:
> > ...which means -m32 would stop working, which means my $DAYJOB would 
> > have to change distros on our build machines.
> >
> > We rely on being able to build 32- and 64-bit binaries as part of the 
> > same build. How exactly is that supposed to work with mock?
>  
>  Well in our production environment we require clean chroots be created
>  for every build, so we create a clean i386 chroot to build the i386
>  binaries, we create a clean x86_64 chroot to build the x86_64 binaries,
>  we create a clean ppc chroot to create the ppc binaries, I think you see
>  where I'm going with this. 
Obviously your requirements are different. (For us, I've no idea how 
hard something like the above would be to achieve on OSF 5.x or Irix 
6.x. Yes, I work with those platforms.)

Our requirements are that one build environment produces one package 
containing both 32- and 64-bit binaries. (Including, in one case, on 
Windoze, and don't even get me started on what a PITA *that* is.) We 
support enough platforms without multiplying the support cost with 
separate packages based on what size you want your pointers to be...

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Use the --force, Luke -- Riccardo Iaconelli

[Kevin Kofler]

Matthew Woehlke wrote:
>  Our requirements are that one build environment produces one package
>  containing both 32- and 64-bit binaries. 
If you're talking about RPM packages, that's completely broken, an x86_64
RPM is supposed to only contain x86_64 stuff (and it won't install on
32-bit systems), and an i386 RPM definitely must not contain 64-bit stuff.

        Kevin Kofler

[Richard W.M. Jones]

On Sun, Apr 26, 2009 at 08:09:28AM +0200, Kevin Kofler wrote:
>  Matthew Woehlke wrote:
>  > Our requirements are that one build environment produces one package
>  > containing both 32- and 64-bit binaries.
>  
>  If you're talking about RPM packages, that's completely broken, an x86_64
>  RPM is supposed to only contain x86_64 stuff (and it won't install on
>  32-bit systems), and an i386 RPM definitely must not contain 64-bit stuff. 
I think it's interesting that three things: (1) cross-compilation, (2)
virtualization and (3) Wine [which is a type of virt] becoming usable,
have all happened at around the same time, and I don't think it's a
coincidence.

It means what you said above isn't really true any more, or more
circumspectly, if what you said is true, then RPM isn't designed for
this new world.

Some examples:

Since Wine reached 1.0 a few years ago and became usable, it now
becomes practical to build and test software on Fedora.  Hence the
Windows cross-compiler project.  "noarch" RPMs contain Windows
libraries.

With virtualization now commonplace, you can no longer assume that the
architecture you build on will be the architecture you run on.  It's
quite possible, in fact desirable, to store programs in an RPM of a
different architecture, that will run in (eg) qemu.  An example of
this is virt-p2v and the V2V tools, where we store drivers for all
sorts of different platforms and architectures inside the RPM.

With appliances, it's quite desirable to want a 32 bit appliance
stored alongside a 64 bit program.  32 bit appliances are generally
better because of the qualities of appliances: They run in a VM, so
host architecture doesn't matter.  They run in very little memory, so
64 bit isn't useful.  You want them to be as small as possible, and
(sometimes, not always) 32 bit binaries are smaller.

In the actual appliances cases I'm looking at now, we really want to
mix not just 32 and 64 bit, but all combinations of architectures,
such as having x86-64 library linked with a (eg) ppc32 appliance.

[I should also add as a note here that I'm not talking about binary
blobs, firmware etc.  All of the above cases are built from source.]

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/

[Daniel P. Berrange]

On Sun, Apr 26, 2009 at 08:09:28AM +0200, Kevin Kofler wrote:
>  Matthew Woehlke wrote:
>  > Our requirements are that one build environment produces one package
>  > containing both 32- and 64-bit binaries.
>  
>  If you're talking about RPM packages, that's completely broken, an x86_64
>  RPM is supposed to only contain x86_64 stuff (and it won't install on
>  32-bit systems), and an i386 RPM definitely must not contain 64-bit stuff. 
As Rich mentions, there's a tricky situation with virtualization around,
and with cross-compilation/emulation.  For QEMU we've had to jump through
some nasty hoops to build the firmware/BIOS files. ie, the QEMU i686
emulator is built on all Fedora archs, but building the BIOS files to
actually make it work needs an i686 host. So we have to build on one
arch, get the built blobs and then include these pre-built files in a
second build done for the non-x86 archs. Similar fun building PPC, sparc
blobs on i686, etc. 


Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

[Andreas Thienemann]

On Mon, 27 Apr 2009, Daniel P. Berrange wrote:

>  As Rich mentions, there's a tricky situation with virtualization
> around,
>  and with cross-compilation/emulation.  For QEMU we've had to jump through
>  some nasty hoops to build the firmware/BIOS files. ie, the QEMU i686
>  emulator is built on all Fedora archs, but building the BIOS files to
>  actually make it work needs an i686 host. So we have to build on one
>  arch, get the built blobs and then include these pre-built files in a
>  second build done for the non-x86 archs. Similar fun building PPC, sparc
>  blobs on i686, etc.  
I remember the OpenMoko build scripts needing similar tricks where (I 
think) localization and some other files had to be built on a native arm 
system.

They ended up using qemu in user mode emulation to have a "native"  
system.

Maybe that's a solution for your bios file needs as well?

regards,
 andreas

[Kevin Kofler]

Andreas Thienemann wrote:
>  They ended up using qemu in user mode emulation to have a
> "native"
>  system.
>  
>  Maybe that's a solution for your bios file needs as well? 
Not really, it'd also need all the target packages in the Koji buildroot,
which is not going to happen. Especially for targets like sparc which
aren't even primary platforms (but can still be emulated on the primary
platforms, so QEMU needs some SPARC binaries).

        Kevin Kofler

[Matthew Woehlke]

Kevin Kofler wrote:
>  Matthew Woehlke wrote:
> > Our requirements are that one build environment produces one package
> > containing both 32- and 64-bit binaries.
>  
>  If you're talking about RPM packages, [snip] 
Nope. Custom installer. Has to work on lots of platforms without rpm 
(including, in theory, non-rpm GNU/Linux, but also Solaris, HP-UX, etc.).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
What sort of trite mind
Didst produce this signature
 From random input

[Colin Walters]

On Mon, Apr 20, 2009 at 4:22 AM, Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  On Sun, Apr 19, 2009 at 06:43:10PM -0400, Orcan Ogetbil wrote:
> > This is a dilemma we have in Fedora. I have no idea why someone would
> > want to keep the devel subpackages of the same package with different
> > archs installed.
>
>  Because one wants to compile with 'gcc -m32'.  This is very useful
>  when you have virtualization.
>
>  Unfortunately the more I look at multilib, the more totally broken it
>  seems to be. 
multilib isn't broken, rather it has a limited scope.  It solves the
problems it was intended to well enough.  What we really need is an
explicit enumeration of the kinds of issues multilib is addressing,
and those that are outside the scope.

The things that are outside the scope include general software compilation.

[Tom Lane]

=?iso-8859-1?q?Bj=F6rn_Persson?= <bjorn(a)xn--rombobjrn-67a.se&gt; writes:
>  I know that compiled libraries can be installed in both 32-bit and
> 64-bit 
>  versions at the same time, but is this required for -devel packages as well?  
Yes, up to a point.  I am not sure if recent Fedora versions have
improved on matters (there was talk of improvement awhile back --- eg
https://fedoraproject.org/wiki/BillNottingham/MultilibDraft).  But the
way it works for RHEL packages is that multilib conflicts are only
allowed for binary executable files, and I think only if they're in
standard locations such as /usr/bin, /sbin, etc.  For example, if your
-devel package has to install /usr/include/mypackage.h, then the 32-bit
and 64-bit versions must install *identical* copies of that file.

Now if mypackage.h comes straight from the upstream distro, this is
no problem.  For files generated during build (think mypackage-config.h)
it is a big problem, since such files often contain arch-specific
values.  The standard workaround is to install the actual generated
file as, say, /usr/include/mypackage-config-i386.h or
/usr/include/mypackage-config-x86_64.h, and have both packages provide
a textually identical stub file /usr/include/mypackage-config.h that
#include's the right one of these depending on platform #define's.

Actual library files of course aren't a problem since they are under
either /usr/lib or /usr/lib64.

The other common source of conflicts is generated configuration scripts,
eg "/usr/bin/mypackage-config".  The /usr/bin exception I mentioned
above applies only for *binary* executables --- if your package builds a
shell script or something similar that contains configuration values,
it still breaks the rules.  This can be solved with a similar
indirection workaround.  I tend to put the actual generated script
under /usr/lib or /usr/lib64, and then /usr/bin/ has a stub that
invokes the right one of these.

I'm not entirely sure what's the point of this rule, given that if you
have any binary executables the two packages aren't going to be
concurrently installable anyway.  But I suppose a lot of -devel packages
don't need to do that.

You can find examples of how I do this in the mysql and postgresql
package specfiles in CVS.  That stuff is all several years old now,
and there might be better ways that have evolved in the meantime
(especially if you only care about recent Fedora releases).
I'd be interested to find out more about how other people do it.

			regards, tom lane

[Kevin Kofler]

Tom Lane wrote:
>  I'm not entirely sure what's the point of this rule, given
> that if you
>  have any binary executables the two packages aren't going to be
>  concurrently installable anyway.  But I suppose a lot of -devel packages
>  don't need to do that. 
The idea is that it should not matter which binary is run, e.g. whether you
run 32-bit or 64-bit bison, you'll (hopefully) get the same generated
parser.

Of course this breaks horribly if the binary is something like kde4-config
(you'll want kde4-config --libsuffix and the like to return different
results for 32-bit or 64-bit builds), and we don't have a good solution for
that. (Yes, kde4-config is an ELF binary, not a script.)

        Kevin Kofler

[Callum Lerwick]

On Tue, 2009-04-21 at 03:07 +0200, Kevin Kofler wrote:
>  Tom Lane wrote:
>  > I'm not entirely sure what's the point of this rule, given that if you
>  > have any binary executables the two packages aren't going to be
>  > concurrently installable anyway.  But I suppose a lot of -devel packages
>  > don't need to do that.
>  
>  The idea is that it should not matter which binary is run, e.g. whether you
>  run 32-bit or 64-bit bison, you'll (hopefully) get the same generated
>  parser.
>  
>  Of course this breaks horribly if the binary is something like kde4-config
>  (you'll want kde4-config --libsuffix and the like to return different
>  results for 32-bit or 64-bit builds), and we don't have a good solution for
>  that. (Yes, kde4-config is an ELF binary, not a script.) 
Because KDE always has to be different and inevitably manages to Do It
Wrong.

[Kevin Kofler]

Callum Lerwick wrote:
>  Because KDE always has to be different and inevitably manages to Do
> It
>  Wrong. 
How else are scripts supposed to figure out whether the current distribution
and platform uses lib64 or lib or even lib32? Other than
kde4-config --libsuffix (or the KDE 3 kde-config --libsuffix), I don't
really see a clean way.

        Kevin Kofler

[Callum Lerwick]

On Tue, 2009-04-21 at 06:05 +0200, Kevin Kofler wrote:
>  Callum Lerwick wrote:
>  > Because KDE always has to be different and inevitably manages to Do It
>  > Wrong.
>  
>  How else are scripts supposed to figure out whether the current distribution
>  and platform uses lib64 or lib or even lib32? Other than
>  kde4-config --libsuffix (or the KDE 3 kde-config --libsuffix), I don't
>  really see a clean way. 
What scripts that do what? Why does no other software in Fedora seem to
have this problem? Why do I have to have
QTDIR/QTINC/QTLIB/QT_PLUGIN_PATH crap in my environment? Why is kdelibs
among the biggest packages on my system?

...Why is libgweather alone bigger than kdelibs? Why isn't everything
in /usr/share/gnome/help marked %doc?

Bloat bloat bloat bloat. Wait what was I talking about...

[Kevin Kofler]

Callum Lerwick wrote:
>  ...Why is libgweather alone bigger than kdelibs? 
http://forums.thedailywtf.com/forums/p/11394/195305.aspx
(No, I'm not the one who posted that thread.)

        Kevin Kofler

[Callum Lerwick]

On Tue, 2009-04-21 at 08:07 +0200, Kevin Kofler wrote:
>  Callum Lerwick wrote:
>  > ...Why is libgweather alone bigger than kdelibs?
>  
>  http://forums.thedailywtf.com/forums/p/11394/195305.aspx
>  (No, I'm not the one who posted that thread.) 
Dear god.

$ cat /usr/share/libgweather/* > /tmp/gweather
$ ls -lh /tmp/gweather
-rw-rw-r--. 1 seg seg  75M 2009-04-21 02:22 /tmp/gweather
$ lzma --best -v /tmp/gweather 
/tmp/gweather:	 98.1% -- replaced with /tmp/gweather.lzma
$ ls -lh /tmp/gweather.lzma
-rw-rw-r--. 1 seg seg 1.5M 2009-04-21 02:11 /tmp/gweather.lzma

73.5M, 98.1% compression! It's only 1.5mb of actual data! Are the
libgweather developers trying to win some kind of award for most bloat?

Someone needs to rethink their data structure. There is an immense
amount of duplicated data between languages. And an absurd amount of XML
overhead.

[Tom Lane]

Callum Lerwick <seg(a)haxxed.com&gt; writes:
>  On Tue, 2009-04-21 at 03:07 +0200, Kevin Kofler wrote:
> > Of course this breaks horribly if the binary is something like kde4-config
> > (you'll want kde4-config --libsuffix and the like to return different
> > results for 32-bit or 64-bit builds), and we don't have a good solution for
> > that. (Yes, kde4-config is an ELF binary, not a script.) 
>  Because KDE always has to be different and inevitably manages to Do
> It
>  Wrong. 
So, I suppose you can tell me how to do it better?  mysql-config and
similar programs have the same issue, so I'm awaiting your wisdom
with bated breath.

Actually the only reason that mysql-config is a binary and not a script
is that there doesn't seem to be any other good way for it to know which
word-width it's supposed to return results for.  This is one of the main
problems with trying to do software builds in a multilib environment.

			regards, tom lane

[Orcan Ogetbil]

On Tue, Apr 21, 2009 at 4:11 PM, Tom Lane wrote:
>  Callum Lerwick writes:
> > On Tue, 2009-04-21 at 03:07 +0200, Kevin Kofler wrote:
> >> Of course this breaks horribly if the binary is something like kde4-config
> >> (you'll want kde4-config --libsuffix and the like to return different
> >> results for 32-bit or 64-bit builds), and we don't have a good solution for
> >> that. (Yes, kde4-config is an ELF binary, not a script.)
>
> > Because KDE always has to be different and inevitably manages to Do It
> > Wrong.
>
>  So, I suppose you can tell me how to do it better?  mysql-config and
>  similar programs have the same issue, so I'm awaiting your wisdom
>  with bated breath.
>
>  Actually the only reason that mysql-config is a binary and not a script
>  is that there doesn't seem to be any other good way for it to know which
>  word-width it's supposed to return results for.  This is one of the main
>  problems with trying to do software builds in a multilib environment.
>
>                         regards, tom lane
>  
What is wrong with renaming the xxxxx-config binary to
xxxxx-config.%{arch} (or moving it to %{_libdir}) and writing a
platform independent shell script xxxxx-config that will call the
correct xxxxx-config.%{arch} file?

Orcan

[Tom Lane]

Orcan Ogetbil <oget.fedora(a)gmail.com&gt; writes:
>  On Tue, Apr 21, 2009 at 4:11 PM, Tom Lane wrote:
> > Actually the only reason that mysql-config is a binary and not a script
> > is that there doesn't seem to be any other good way for it to know which
> > word-width it's supposed to return results for. This is one of the main
> > problems with trying to do software builds in a multilib environment. 
>  What is wrong with renaming the xxxxx-config binary to
>  xxxxx-config.%{arch} (or moving it to %{_libdir}) and writing a
>  platform independent shell script xxxxx-config that will call the
>  correct xxxxx-config.%{arch} file? 
How is the platform independent shell script to know which arch-specific
file to call?  (This is an actual question, not a rhetorical one.)
AFAIK there is nothing it can look at that isn't likely to do the Wrong
Thing from the perspective of someone trying to build software.

			regards, tom lane

[Orcan Ogetbil]

On Tue, Apr 21, 2009 at 5:50 PM, Tom Lane wrote:
>  Orcan Ogetbil writes:
> > On Tue, Apr 21, 2009 at 4:11 PM, Tom Lane wrote:
> >> Actually the only reason that mysql-config is a binary and not a script
> >> is that there doesn't seem to be any other good way for it to know which
> >> word-width it's supposed to return results for. This is one of the main
> >> problems with trying to do software builds in a multilib environment.
>
> > What is wrong with renaming the xxxxx-config binary to
> > xxxxx-config.%{arch} (or moving it to %{_libdir}) and writing a
> > platform independent shell script xxxxx-config that will call the
> > correct xxxxx-config.%{arch} file?
>
>  How is the platform independent shell script to know which arch-specific
>  file to call?  (This is an actual question, not a rhetorical one.)
>  AFAIK there is nothing it can look at that isn't likely to do the Wrong
>  Thing from the perspective of someone trying to build software.
>
>                         regards, tom lane 
This is only for preventing file conflicts between RPMs. Honestly, as
I said before, I really don't understand the need of keeping different
arch devel packages in the same system at the same time.

Just remove one and install another. You can even write a simple
script to do this. Create a local repo if you are worried about the
time loss.

If you are dying for keeping different arch devel packages in the same
system, you can write your code accordingly.

Orcan

[Callum Lerwick]

On Tue, 2009-04-21 at 18:14 -0400, Orcan Ogetbil wrote:
>  This is only for preventing file conflicts between RPMs. Honestly,
> as
>  I said before, I really don't understand the need of keeping different
>  arch devel packages in the same system at the same time. 
Why would you need to avoid conflicts if you're *not* going to install
them both at the same time?

>  Just remove one and install another. You can even write a simple
>  script to do this. Create a local repo if you are worried about the
>  time loss. 
Why would I want to run a root command that screws with my root
filesystem as part of my edit-compile-test cycle?

$ gcc -O2 -Wall -m32 hello.c -o hello
$ file ./hello
./hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not
stripped
$ ./hello
Hello world!
$ gcc -O2 -Wall -m64 hello.c -o hello
$ file ./hello
./hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not
stripped
$ ./hello
Hello world!
$ i686-pc-mingw32-gcc -O2 -Wall hello.c -o hello.exe
$ file ./hello.exe 
./hello.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit
$ ./hello.exe 
Hello world!
$ mipsel-uclibc-gcc -O2 -Wall hello.c -o hello
$ file ./hello
./hello: ELF 32-bit LSB executable, MIPS, MIPS-II version 1 (SYSV),
dynamically linked (uses shared libs), not stripped
$ qemu-mipsel -L /opt/brcm/hndtools-mipsel-uclibc/ ./hello
Hello world!


Why must you insist on making my life more difficult than it already is?
Why do we even bother having an -m32 flag in gcc if we're not going to
use it?

[Orcan Ogetbil]

On Tue, Apr 21, 2009 at 11:30 PM, Callum Lerwick wrote:
>  On Tue, 2009-04-21 at 18:14 -0400, Orcan Ogetbil wrote:
> > This is only for preventing file conflicts between RPMs. Honestly, as
> > I said before, I really don't understand the need of keeping different
> > arch devel packages in the same system at the same time.
>
>  Why would you need to avoid conflicts if you're *not* going to install
>  them both at the same time?
>
> > Just remove one and install another. You can even write a simple
> > script to do this. Create a local repo if you are worried about the
> > time loss.
>
>  Why would I want to run a root command that screws with my root
>  filesystem as part of my edit-compile-test cycle?
>
>  $ gcc -O2 -Wall -m32 hello.c -o hello
>  $ file ./hello
>  ./hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
>  dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not
>  stripped
>  $ ./hello
>  Hello world!
>  $ gcc -O2 -Wall -m64 hello.c -o hello
>  $ file ./hello
>  ./hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
>  dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not
>  stripped
>  $ ./hello
>  Hello world!
>  $ i686-pc-mingw32-gcc -O2 -Wall hello.c -o hello.exe
>  $ file ./hello.exe
>  ./hello.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit
>  $ ./hello.exe
>  Hello world!
>  $ mipsel-uclibc-gcc -O2 -Wall hello.c -o hello
>  $ file ./hello
>  ./hello: ELF 32-bit LSB executable, MIPS, MIPS-II version 1 (SYSV),
>  dynamically linked (uses shared libs), not stripped
>  $ qemu-mipsel -L /opt/brcm/hndtools-mipsel-uclibc/ ./hello
>  Hello world!
>
>
>  Why must you insist on making my life more difficult than it already is?
>  Why do we even bother having an -m32 flag in gcc if we're not going to
>  use it?
>  
Ah, those folks who feel the need of testing their program in all
archs after every other line of coding can use an interpreter based
language. It will be less pain for all parties.

Also, you can make the arch-independent xxxxx-config script smarter,
so that whenever you pass a magic flag it will redirect you to the
correct binary. If you don't pass the magic flag it will default to
`uname -i`. When I said, "

>  If you are dying for keeping different arch devel packages in the
> same
>  system, you can write your code accordingly. 
", I meant such usage.

Orcan

[Callum Lerwick]

On Wed, 2009-04-22 at 11:40 -0400, Orcan Ogetbil wrote:
>  Ah, those folks who feel the need of testing their program in all
>  archs after every other line of coding can use an interpreter based
>  language. It will be less pain for all parties. 
I'm optimizing performance critical code that runs on a wide variety of
platforms. I need to know how fast it is, on a wide variety of
platforms, as fast as possible. Otherwise I'm just sitting on my hands
being a dick on fedora-devel waiting for results. Something that doubles
speed on an Athlon 64 quite likely halves the speed on a Celeron.

... So no, python isn't going to cut it.

The point is I can easily cross compile for Win32 and MIPS on the same
x86_64 box, why does i386 have to be a pain in the ass?

Why don't we just move all x86_64 headers to /usr/include64, hack GCC to
look there instead when compiling x86_64, and be done with it? Includes
are apparently arch-specific, so it's a crock they're not split the same
way as lib.

[Tom Lane]

Callum Lerwick <seg(a)haxxed.com&gt; writes:
>  Why don't we just move all x86_64 headers to /usr/include64, hack
> GCC to
>  look there instead when compiling x86_64, and be done with it? 
That doesn't solve the problem.  The part of the problem that's actually
not solved today is the /usr/bin/foo-config problem.  Without a fix for
that, making it a bit easier to deal with include-file diffs isn't
worth anything.

			regards, tom lane

[Callum Lerwick]

On Wed, 2009-04-22 at 13:59 -0400, Tom Lane wrote:
>  Callum Lerwick <seg(a)haxxed.com&gt; writes:
>  > Why don't we just move all x86_64 headers to /usr/include64, hack GCC to
>  > look there instead when compiling x86_64, and be done with it?
>  
>  That doesn't solve the problem.  The part of the problem that's actually
>  not solved today is the /usr/bin/foo-config problem.  Without a fix for
>  that, making it a bit easier to deal with include-file diffs isn't
>  worth anything. 
The same way cross compilation identifies gcc and strip and whatnot.
Prefix it with the architecture. It just so happens autotools and
pkg-config already do this:

$ rpm -qf /usr/bin/mingw32-pkg-config
mingw32-filesystem-50-3.fc11.noarch
$ tail -n 5 /usr/bin/mingw32-pkg-config
# This is a useful command-line script through which one can use the
# macros from mingw32-macros.mingw32 cross-compilation. 

NAME="_`basename $0|tr -- - _`"
eval "`rpm --eval "%{$NAME}"`" "$@"

... Hrm, Richard went about this differently than I did. Seems rather
rpm-centric...

$ rpm --eval "%{_mingw32_pkg_config}"

  PKG_CONFIG_LIBDIR="/usr/i686-pc-mingw32/sys-root/mingw/lib/pkgconfig";
export PKG_CONFIG_LIBDIR; 
  unset PKG_CONFIG_PATH; 
  pkg-config

[Tom Lane]

Callum Lerwick <seg(a)haxxed.com&gt; writes:
>  On Wed, 2009-04-22 at 13:59 -0400, Tom Lane wrote:
> > That doesn't solve the problem.  The part of the problem that's actually
> > not solved today is the /usr/bin/foo-config problem.  Without a fix for
> > that, making it a bit easier to deal with include-file diffs isn't
> > worth anything. 
>  The same way cross compilation identifies gcc and strip and whatnot.
>  Prefix it with the architecture. 
Which immediately breaks all the upstream configure scripts that are
trying to use the config program in the first place.  You can get away
with renaming the compiler because there's twenty years of precedent
for not hard-coding the value of $(CC), and workable infrastructure for
build processes to avoid assuming anything about it.  There is no
precedent or infrastructure for dependent packages to find mysql-config
under any name but that one.

The approach that I thought about when I first ran into this problem
was to have the config script examine the value of `uname -i` to decide
which output to produce.  I remember being told that that wasn't
acceptable, but I do not recall exactly why not.

			regards, tom lane

[Jesse Keating]

On Wed, 2009-04-22 at 15:04 -0400, Tom Lane wrote:
>  
>  The approach that I thought about when I first ran into this problem
>  was to have the config script examine the value of `uname -i` to decide
>  which output to produce.  I remember being told that that wasn't
>  acceptable, but I do not recall exactly why not. 
It would likely require use of 'setarch i386' before calling the script
in order for uname -i to output the 32bit you may be targeting in that
run, which people may not expect.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Tom Lane]

Jesse Keating <jkeating(a)redhat.com&gt; writes:
>  On Wed, 2009-04-22 at 15:04 -0400, Tom Lane wrote:
> > The approach that I thought about when I first ran into this problem
> > was to have the config script examine the value of `uname -i` to decide
> > which output to produce.  I remember being told that that wasn't
> > acceptable, but I do not recall exactly why not. 
>  It would likely require use of 'setarch i386' before calling
> the script
>  in order for uname -i to output the 32bit you may be targeting in that
>  run, which people may not expect. 
Right, it absolutely would require you to setarch before launching a
build for the 32-bit arch.  The question is why that's so unworkable.
Especially when the present alternative just plain doesn't work.

I note that it's already expected by a lot of spec files (or at least
by several of mine) that `uname -i` correctly reports the target arch.

			regards, tom lane

[Jesse Keating]

On Wed, 2009-04-22 at 15:22 -0400, Tom Lane wrote:
>  Right, it absolutely would require you to setarch before launching a
>  build for the 32-bit arch.  The question is why that's so unworkable.
>  Especially when the present alternative just plain doesn't work.
>  
>  I note that it's already expected by a lot of spec files (or at least
>  by several of mine) that `uname -i` correctly reports the target arch. 
I honestly don't know.  I don't see much wrong with it.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Callum Lerwick]

On Wed, 2009-04-22 at 15:04 -0400, Tom Lane wrote:
>  Callum Lerwick <seg(a)haxxed.com&gt; writes:
>  > On Wed, 2009-04-22 at 13:59 -0400, Tom Lane wrote:
>  >> That doesn't solve the problem.  The part of the problem that's
> actually
>  >> not solved today is the /usr/bin/foo-config problem.  Without a fix for
>  >> that, making it a bit easier to deal with include-file diffs isn't
>  >> worth anything.
>  
>  > The same way cross compilation identifies gcc and strip and whatnot.
>  > Prefix it with the architecture.
>  
>  Which immediately breaks all the upstream configure scripts that are
>  trying to use the config program in the first place. 
Native compilation will work just fine. The un-prefixed config-foo
remains in place for the native architecture. Just like gcc.

And yes, it will break build scripts. Because the build scripts are
depending on something that is _broken_right_now_. That's the whole
point here.

[Colin Walters]

On Wed, Apr 22, 2009 at 1:27 PM, Callum Lerwick <seg(a)haxxed.com&gt; wrote:

>  Why don't we just move all x86_64 headers to /usr/include64, hack
> GCC to
>  look there instead when compiling x86_64, and be done with it? 
Because multilib is just a crutch for running old/proprietary 32 bit code.

If you're a software developer, we generally require greater
resources.  So it shouldn't be a big deal to have a few gigs to
dedicate to an i386 mock root or use virtualization.

[Callum Lerwick]

On Wed, 2009-04-22 at 14:36 -0400, Colin Walters wrote:
>  On Wed, Apr 22, 2009 at 1:27 PM, Callum Lerwick
> <seg(a)haxxed.com&gt; wrote:
>  
>  > Why don't we just move all x86_64 headers to /usr/include64, hack GCC to
>  > look there instead when compiling x86_64, and be done with it?
>  
>  Because multilib is just a crutch for running old/proprietary 32 bit code.
>  
>  If you're a software developer, we generally require greater
>  resources.  So it shouldn't be a big deal to have a few gigs to
>  dedicate to an i386 mock root or use virtualization. 
But _I_ _do_ _not_ _have_ _to_ _do_ _this_ _for_ _Win32_ _or_ _mipsel_.
Why is i386 special?

[Colin Walters]

On Wed, Apr 22, 2009 at 2:47 PM, Callum Lerwick <seg(a)haxxed.com&gt; wrote:
>  But _I_ _do_ _not_ _have_ _to_ _do_ _this_ _for_ _Win32_ _or_ _mipsel_.
>  Why is i386 special? 
Because you're trying to take the multilib system and gcc -m32, which
aren't the same thing as the mingw-* and arm-* package sets.

Anyways I'm not an expert on cross compilation - multilib is already
pain enough =)  If there's a way you can make it work without massive
platform changes, more power to you.  But things like changing to
include64 are just not in the scope of multi*lib*.

[Chris Adams]

Once upon a time, Callum Lerwick <seg(a)haxxed.com&gt; said:
>  But _I_ _do_ _not_ _have_ _to_ _do_ _this_ _for_ _Win32_ _or_
> _mipsel_.
>  Why is i386 special? 
When you compile for Win32, you are using a cross-compiler environment.
Everything about it is different; different includes, compilers,
libraries, etc.

Now, Linux/i386 could be set up that way on Linux/x86_64, but that would
require rebuilding the development stack for cross-compilation
(different compilers, development packages, etc.).  This is not the same
as multilib (which allows i386 and x86_64 binaries to co-exist).

Nobody is interested in putting that much work into that setup,
especially when you can just use mock (since i386 binaries can run
natively on x86_64).

What is wrong with using mock?  It takes a little more disk space, and
you have the one-time hit of creating the root, but then it runs just
fine.  Mock isn't just for building RPMs; with copyin, copyout, and
shell, you can use it for all kinds of work.

-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Tom Lane]

Chris Adams <cmadams(a)hiwaay.net&gt; writes:
>  What is wrong with using mock? 
Not a lot.  The annoying thing is that the system will let you install
32-bit and 64-bit devel packages concurrently, and it *looks like*
that should be useful for something.  It isn't at the moment, because
of the foo-config-binary problem.  As a packager I'd feel better if
I weren't shipping packages containing such a bogosity.

			regards, tom lane

[Callum Lerwick]

On Wed, 2009-04-22 at 14:48 -0500, Chris Adams wrote:
>  Once upon a time, Callum Lerwick <seg(a)haxxed.com&gt; said:
>  > But _I_ _do_ _not_ _have_ _to_ _do_ _this_ _for_ _Win32_ _or_ _mipsel_.
>  > Why is i386 special?
>  
>  When you compile for Win32, you are using a cross-compiler environment.
>  Everything about it is different; different includes, compilers,
>  libraries, etc. 
Same thing with multilib. Only difference is i386 and x86_64 are mashed
together in the same tree, with the exception of lib/lib64. (and the
i386/x86_64 gcc is mashed together, but that's an implementation
detail.)

This implementation was fundamentally flawed to begin with. But hey, how
could whoever came up with it have known at the time?

Years later, it's clear what's wrong. Turns out /usr/include is in fact
arch specific. And various people's config-foo dealies are Doing It
Wrong.

... And I've given solutions to both of those. What other problems are
there with multilib?

>  Now, Linux/i386 could be set up that way on Linux/x86_64, but that
> would
>  require rebuilding the development stack for cross-compilation
>  (different compilers, development packages, etc.).  This is not the same
>  as multilib (which allows i386 and x86_64 binaries to co-exist). 
That's my whole point here. If we're having problems with multilib, it's
because multilib is not ENOUGH like cross compiling.

>  Nobody is interested in putting that much work into that setup,
>  especially when you can just use mock (since i386 binaries can run
>  natively on x86_64). 
Pimpin' ain't easy.

Is fixing it right any less painful than maintaining the current setup?

That's how this thread started. People bitching about what a pain
maintaining multilib is.

>  What is wrong with using mock? 
It's slow, awkward and completely un-neccessary.

[Richard W.M. Jones]

On Thu, Apr 23, 2009 at 04:19:57PM -0500, Callum Lerwick wrote:
>  On Wed, 2009-04-22 at 14:48 -0500, Chris Adams wrote:
>  > What is wrong with using mock?
>  
>  It's slow, awkward and completely un-neccessary. 
And needs root to go and set it up.  And can't be nested.

Mock, for example, isn't useful for us building 32 bit appliances on
64 bit machines.  (Neither is multilib for that matter - we really do
need real cross-compilation and/or febootstrap + qemu).

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/

[Seth Vidal]

On Fri, 24 Apr 2009, Richard W.M. Jones wrote:

>  On Thu, Apr 23, 2009 at 04:19:57PM -0500, Callum Lerwick wrote:
> > On Wed, 2009-04-22 at 14:48 -0500, Chris Adams wrote:
> >> What is wrong with using mock?
> >
> > It's slow, awkward and completely un-neccessary.
>
>  And needs root to go and set it up.  And can't be nested.
>
>  Mock, for example, isn't useful for us building 32 bit appliances on
>  64 bit machines. 

Why not? I've built lots of 32 bit packages on 64bit machines using mock 
and setarch.

-sv

[Jesse Keating]

On Fri, 2009-04-24 at 10:19 -0400, Seth Vidal wrote:
>  
>  
>  Why not? I've built lots of 32 bit packages on 64bit machines using mock 
>  and setarch. 
He may be talking about whatever it is that keeps livecd-creator from
being ran inside mock chroots, which I think is getting fixed.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Seth Vidal]

On Fri, 24 Apr 2009, Jesse Keating wrote:

>  On Fri, 2009-04-24 at 10:19 -0400, Seth Vidal wrote:
> >
> >
> > Why not? I've built lots of 32 bit packages on 64bit machines using mock
> > and setarch.
>
>  He may be talking about whatever it is that keeps livecd-creator from
>  being ran inside mock chroots, which I think is getting fixed. 

Is that a mock issue or a livecd-creator issue?

-sv

[Chris Adams]

Once upon a time, Seth Vidal <skvidal(a)fedoraproject.org&gt; said:
>  On Fri, 24 Apr 2009, Jesse Keating wrote:
>  >He may be talking about whatever it is that keeps livecd-creator from
>  >being ran inside mock chroots, which I think is getting fixed.
>  
>  Is that a mock issue or a livecd-creator issue? 
Isn't it an SELinux issue?
-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Richard W.M. Jones]

On Fri, Apr 24, 2009 at 08:15:59AM -0700, Jesse Keating wrote:
>  On Fri, 2009-04-24 at 10:19 -0400, Seth Vidal wrote:
>  > Why not? I've built lots of 32 bit packages on 64bit machines using mock 
>  > and setarch.
>  
>  He may be talking about whatever it is that keeps livecd-creator from
>  being ran inside mock chroots, which I think is getting fixed. 
I said it in my email further up: you can't nest mock builds, and it
requires extra steps by root to configure mock.

Practically this means that appliances can't be built in mock or Koji.

febootstrap fixes the above and allows appliances to be built inside
mock, because it doesn't need root, or setuid helper programs, or
bind-mounting, or anything else like that.  It runs yum using fakeroot
and fakechroot.  This wasn't possible previously, but I've pushed
upstream sufficient patches to make yum and %post scripts work in
fake{,ch}root environments.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

[Jesse Keating]

On Fri, 2009-04-24 at 16:24 +0100, Richard W.M. Jones wrote:
>  
>  I said it in my email further up: you can't nest mock builds, and it
>  requires extra steps by root to configure mock. 
Please define "nest mock builds"

>  
>  Practically this means that appliances can't be built in mock or Koji. 
Actually there is a pile of patches being created right now that would
allow live image creation within mock.  The user would call a koji
command, and pass either a kickstart file or an SCM url to a kickstart
file and you'll get a live image out the other end.

-- 
Jesse Keating RHCE      (http://jkeating.livejournal.com)
Fedora Project          (http://fedoraproject.org/wiki/JesseKeating)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
identi.ca               (http://identi.ca/jkeating)

[Richard W.M. Jones]

On Fri, Apr 24, 2009 at 08:28:09AM -0700, Jesse Keating wrote:
>  On Fri, 2009-04-24 at 16:24 +0100, Richard W.M. Jones wrote:
>  > 
>  > I said it in my email further up: you can't nest mock builds, and it
>  > requires extra steps by root to configure mock.
>  
>  Please define "nest mock builds" 
Run mock inside mock.

>  > Practically this means that appliances can't be built in
> mock or Koji.
>  
>  Actually there is a pile of patches being created right now that would
>  allow live image creation within mock.  The user would call a koji
>  command, and pass either a kickstart file or an SCM url to a kickstart
>  file and you'll get a live image out the other end. 
I talked to Bryan Kearney about this, and it's a bit different from
what I want.  I'm building very small, single-purpose virtual
machines, which get embedded in the final RPM output.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw

[Chris Adams]

Once upon a time, Richard W.M. Jones <rjones(a)redhat.com&gt; said:
>  I said it in my email further up: you can't nest mock builds, and
> it
>  requires extra steps by root to configure mock. 
"usermod -a -G mock rjones" is not that much work for root.

Of course, you can further restrict it using sudo if you wish.
-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Richard W.M. Jones]

On Fri, Apr 24, 2009 at 10:35:43AM -0500, Chris Adams wrote:
>  Once upon a time, Richard W.M. Jones <rjones(a)redhat.com&gt; said:
>  > I said it in my email further up: you can't nest mock builds, and it
>  > requires extra steps by root to configure mock.
>  
>  "usermod -a -G mock rjones" is not that much work for root.
>  
>  Of course, you can further restrict it using sudo if you wish. 
And edit or create a mock config files for the new mock repo.

Most Unix programs can be built using:

  ./configure
  make

But a program that needs mock has a bunch of other configuration steps
that have to be carried out by root.  OK, maybe not such a problem for
manual builds.  But now if you want to move that into an auto-build
environment (test builds, Koji, etc), you've got a problem.

BTW don't take this as some criticism of mock.  It certainly isn't.
I'm _using_ mock all the time for auto-builds.  I want to build
appilances inside mock.  I'm using febootstrap inside mock.  It all
works great.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 75 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

[Till Maas]

On Fr April 24 2009, Chris Adams wrote:
>  Once upon a time, Richard W.M. Jones <rjones(a)redhat.com&gt; said:
>  > I said it in my email further up: you can't nest mock builds, and it
>  > requires extra steps by root to configure mock.
>
>  "usermod -a -G mock rjones" is not that much work for root.
>
>  Of course, you can further restrict it using sudo if you wish. 
Is it not possible anymore to become root using mock?

Regards,
Till

[Ralf Corsepius]

Tom Lane wrote:
>  Orcan Ogetbil <oget.fedora(a)gmail.com&gt; writes:
> > On Tue, Apr 21, 2009 at 4:11 PM, Tom Lane wrote:
> >> Actually the only reason that mysql-config is a binary and not a script
> >> is that there doesn't seem to be any other good way for it to know which
> >> word-width it's supposed to return results for. This is one of the main
> >> problems with trying to do software builds in a multilib environment.
>  
> > What is wrong with renaming the xxxxx-config binary to
> > xxxxx-config.%{arch} (or moving it to %{_libdir}) and writing a
> > platform independent shell script xxxxx-config that will call the
> > correct xxxxx-config.%{arch} file?
>  
>  How is the platform independent shell script to know which arch-specific
>  file to call?  (This is an actual question, not a rhetorical one.)
>  AFAIK there is nothing it can look at that isn't likely to do the Wrong
>  Thing from the perspective of someone trying to build software. 
To be able to do so, in a perfect world, such a shell script would have 
to receive and to process the CFLAGS being used in calls to gcc.
(c.f. -print-multi-directory, -print-multi-lib, 
-print-multi-os-directory in gcc --help).

Ralf

[Richard W.M. Jones]

On Tue, Apr 21, 2009 at 03:07:40AM +0200, Kevin Kofler wrote:
>  (Yes, kde4-config is an ELF binary, not a script.) 
This could be a barrier to cross-compilation.

Background (I'm sure Kevin knows this ...):

It's generally a good idea for *-config programs to be scripts,
because you need to run them during the build process, and that fails
if it's a native program and you're cross-compiling.  The exception is
pkg-config, since it can be configured to do the right thing by
setting some environment variables.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/

[Callum Lerwick]

On Tue, 2009-04-21 at 12:41 +0100, Richard W.M. Jones wrote:
>  On Tue, Apr 21, 2009 at 03:07:40AM +0200, Kevin Kofler wrote:
>  > (Yes, kde4-config is an ELF binary, not a script.)
>  
>  This could be a barrier to cross-compilation.
>  
>  Background (I'm sure Kevin knows this ...):
>  
>  It's generally a good idea for *-config programs to be scripts,
>  because you need to run them during the build process, and that fails
>  if it's a native program and you're cross-compiling.  The exception is
>  pkg-config, since it can be configured to do the right thing by
>  setting some environment variables. 
... Because pkg-config is an engine that reads platform independent
data. Much like a script interpreter running a script. :P

[Kevin Kofler]

Richard W.M. Jones wrote:

>  On Tue, Apr 21, 2009 at 03:07:40AM +0200, Kevin Kofler wrote:
> > (Yes, kde4-config is an ELF binary, not a script.)
>  
>  This could be a barrier to cross-compilation. 
As kde4-config is horribly broken for W32 anyway (the main problem is that
it doesn't understand KDE being relocated to a different path than it was
built for, which is commonly done on W32), KDE's CMake scripts avoid its
use it for W32 builds anyway, so this shouldn't matter at least for MinGW.
It could be a problem for GNU/Linux->GNU/Linux cross builds though. (I'm
not sure anybody tested those at all yet.)

There is experimental support for cross-compiling KDE with cross-MinGW:
http://techbase.kde.org/Getting_Started/Build/KDE4/Windows/Cross-Compiling

        Kevin Kofler

[Björn Persson]

Thank you all for your answers. I'll try to make sure that any arch-specific 
files have arch-specific pathnames.

Björn Persson