10:48 a.m.
I've been talking with some of the SuSE guys and we agree there's some
overlap or at least coordination between their buildsystem and ours. The
first obvious low hanging fruit is common macros. For those who wonder
"why would we help OpenSuSE?" the answer is common goals, and better user
experiences.
The problem is time and coordination. So on a whim I thought I'd send
this email out. Do we have any contributors out there who are both
members of Fedora and SuSE who would be willing to lead this charge, find
similarities and places for coordination?
-Mike
11 a.m.
On Tue, 16 Dec 2008, Mike McGrath wrote:
I've been talking with some of the SuSE guys and we agree
there's some
overlap or at least coordination between their buildsystem and ours. The
first obvious low hanging fruit is common macros. For those who wonder
"why would we help OpenSuSE?" the answer is common goals, and better user
experiences.
You sure about there being much overlap and thus a certain incentive to
develop common macros?
The last time I was paid to look at SuSE was around 2003 or so and back
then there was not much common except the .spec suffix.
BuildRequires weren't used at all (admittedly, Red Hat was rather frugal
wrt BRs) and I haven't seen much use of %macros at all.
AFAICS BuildRequirements were implemented by parsing #-commented lines and
adding the named packages to the dependency list.
Has this behaviour changed?
On the other hand: Is the buildsystem the right place to work on common
goals? I'd assume that specifically for macros, rpm.org is a better place.
regards,
andreas
11:45 a.m.
On Tuesday 16 December 2008 10:48:48 am Mike McGrath wrote:
I've been talking with some of the SuSE guys and we agree
there's some
overlap or at least coordination between their buildsystem and ours. The
first obvious low hanging fruit is common macros. For those who wonder
"why would we help OpenSuSE?" the answer is common goals, and better user
experiences.
The problem is time and coordination. So on a whim I thought I'd send
this email out. Do we have any contributors out there who are both
members of Fedora and SuSE who would be willing to lead this charge, find
similarities and places for coordination?
I think that common macros needs to be solved at rpm.org level. not a
buildsystem level. koji has no say in any of the macros it uses what is
defined inside the distro. the macros fedora uses are defined in rpm and redhat-
rpm-config, the disttag macro is defined in fedora-release.
I see great benefit to everyone by having that problem solved at the rpm.org
level. it will make it much easier to pickup packages and fixes cross distro.
that is not a bad thing. especially for ISV's and upstreams supporting all
distros they only need to do the work once and build everywhere.
Working directly with them to fix issues for there buildsystem however I feel
causes some conflicts. namely it legitimises the use of there buildsystem for
building fedora/RHEL packages. I know people use it and will continue to do
so. but I would ask why? is there some service that fedora could provide and
is not? is it because you can be lazy and sloppy in the packaging and it lets
you? is it just being able to do it in a single place?
We do need to get out of the business of running two buildsystems. we really
do need to be able to build EPEL in koji. I have scheduled a koji hackfest
for fudcon. so if your there and interested then come help. there is always
#koji on freenode for discussion on koji, so if you cant make it in person
you can be there virtually :)
Dennis
12:31 p.m.
On Tue, 16 Dec 2008 18:00:00 +0100 (CET), Andreas wrote:
AFAICS BuildRequirements were implemented by parsing #-commented
lines and
adding the named packages to the dependency list.
Confirmed.
Has this behaviour changed?
Yes.
http://en.opensuse.org/SUSE_Package_Conventions/RPM_Style#1.3._BuildRequi...
6:38 p.m.
On Tue December 16 2008, Mike McGrath wrote:
The problem is time and coordination. So on a whim I thought I'd
send
this email out. Do we have any contributors out there who are both
members of Fedora and SuSE who would be willing to lead this charge, find
similarities and places for coordination?
There exists already a project to coordinate between even more distributions:
http://distributions.freedesktop.org/wiki/
There was also already a first reachout to unify packaging guidelines:
http://lists.freedesktop.org/archives/distributions/2008-March/000100.html
But there is not much activity.
Regards,
Till
6:57 a.m.
As a developer for a small ISV selling engineering analysis software
(www.cambridgeflowsolutions.com), I'm responsible for packaging our
software into RPMs for clean installation anywhere from e.g. RHL7.3,
SUSE 9, to RHEL5, Fedora 10, and SLES10.
We choose RPM so that it integrates seamlessly into the client's OS
(including MIME types and icons), and can be upgraded/uninstalled
cleanly. It depresses me that most ISVs still use shell-based tar
archive installation and endless LD_LIBRARY_PATH manipulation, simply
because building cross-distribution RPMs is so hard.
This stuff really matters to me - I've spent many days tearing my hair
out with build-related issues. At present, we've a single spec file with
many %if clauses to handle all the different package naming conventions
on SUSE/RedHat over time. There are 60 lines just to select the right
X11 BuildRequires.
In theory, this single source RPM should then build on either
buildsystem. We can't release our source to a public buildsystem, so I
run mock 0.7.2 in-house with some custom buildgroups and buildsys-macros
which I have to maintain to populate the initial chroot.
Trouble is the latest mock (0.9.13) won't build my SUSE-related RPMs
(hangs on some file descriptor during chroot construction). And the SUSE
buildsystem isn't as easy to install locally as mock, so I can't use
that without spending many more days....
Every time a new release arrives from a major Linux distributor, I have
to spend hours trying to cajole my old mock builder to work with it.
I see great benefit to everyone by having that problem solved at the rpm.org
level. it will make it much easier to pickup packages and fixes cross distro.
that is not a bad thing. especially for ISV's and upstreams supporting all
distros they only need to do the work once and build everywhere.
Some things can't be solved at rpm.org: buildrequires package names, how
to distinguish Fedora 4 from RHEL5.
Working directly with them to fix issues for there buildsystem
however I feel
causes some conflicts. namely it legitimises the use of there buildsystem for
building fedora/RHEL packages. I know people use it and will continue to do
so. but I would ask why? is there some service that fedora could provide and
is not? is it because you can be lazy and sloppy in the packaging and it lets
you? is it just being able to do it in a single place?
It shouldn't matter *how* you go from .src.rpm to the binaries. Provided
your package is clear on its dependencies (with clauses for either
platform), who cares if you use SUSE's builder or RedHat's?
From an ISV standpoint: I wish to go from a source RPM to a binary one
for approximately 20 Linux distributions and architectures. I don't mind
coding "if RHEL == 5 use tcp_wrappers, if fedora >=7 use
tcp_wrappers_devel, if suse use tcpd_devel". Just provide me with a
single tool I can run locally which automatically pulls in the
appropriate BuildRequires and generates the binaries. How you distribute
the binaries and manage updates, etc. is a separate issue.
I know this is possible, because I'm currently doing it. But with an
outdated version of mock that needs a reboot if interrupted and some
buildsys-macros which I think could/should be easily provided by the
Linux vendors.
As for why: mutual benefit. I've seen Windows make huge in-roads in the
Engineering sector because of the ease of software admin. No one likes
shell-based installs and custom environment variables. RPMs solve this
with one-click install/uninstall.
Make it easier for ISVs to create RPMs and you make it easier for
companies to choose Linux. Make it harder and ISVs will either reduce
the number of supported Linux vendors, or plump for the more tightly
defined world of Windows.
Simon.
We do need to get out of the business of running two buildsystems. we really
do need to be able to build EPEL in koji. I have scheduled a koji hackfest
for fudcon. so if your there and interested then come help. there is always
#koji on freenode for discussion on koji, so if you cant make it in person
you can be there virtually :)
Dennis
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
7:05 a.m.
Number Cruncher wrote:
...
From an ISV standpoint: I wish to go from a source RPM to a binary
one
for approximately 20 Linux distributions and architectures. I don't mind
coding "if RHEL == 5 use tcp_wrappers, if fedora >=7 use
tcp_wrappers_devel, if suse use tcpd_devel".
FWIW, can't you just buildreq /usr/include/tcpd.h for all of these?
Paul.
7:10 a.m.
Paul Howarth wrote:
Number Cruncher wrote:
...
> From an ISV standpoint: I wish to go from a source RPM to a binary
> one for approximately 20 Linux distributions and architectures. I
> don't mind coding "if RHEL == 5 use tcp_wrappers, if fedora >=7 use
> tcp_wrappers_devel, if suse use tcpd_devel".
FWIW, can't you just buildreq /usr/include/tcpd.h for all of these?
Umm. Yes? An excellent suggestion.
Now, about xorg-x11-devel / XFree86-devel, XFree86-Mesa-libGLU /
xorg-x11-Mesa-libGLU / mesa-libGL-devel / mesa-libGLU-devel /
xorg-x11-Mesa-devel / libX11-devel / ..... ?
Simon.
7:25 a.m.
Number Cruncher wrote:
Paul Howarth wrote:
> Number Cruncher wrote:
> ...
>> From an ISV standpoint: I wish to go from a source RPM to a binary
>> one for approximately 20 Linux distributions and architectures. I
>> don't mind coding "if RHEL == 5 use tcp_wrappers, if fedora >=7 use
>> tcp_wrappers_devel, if suse use tcpd_devel".
>
> FWIW, can't you just buildreq /usr/include/tcpd.h for all of these?
Umm. Yes? An excellent suggestion.
Now, about xorg-x11-devel / XFree86-devel, XFree86-Mesa-libGLU /
xorg-x11-Mesa-libGLU / mesa-libGL-devel / mesa-libGLU-devel /
xorg-x11-Mesa-devel / libX11-devel / ..... ?
Unfortunately the same trick doesn't work there because the include
files (and presumably any others that could be used the same way) moved
around from e.g. /usr/X11R6/include to /usr/include. So I know from
experience what sort of mess you can end up with, e.g. this I have for
mgdiff:
# Red Hat Linux: openmotif + XFree86
%if "%{__distinit}" == "rhl"
BuildRequires: openmotif-devel, XFree86-devel
%define xmkmf /usr/X11R6/bin/xmkmf
%define x11bindir %{_prefix}/X11R6/bin
%define appdefdir %{_prefix}/X11R6/lib/X11/app-defaults
%define x11mandir %{_prefix}/X11R6/man
%endif
# Red Hat Enterprise Linux: Monolithic X + openmotif
%if "%{__distinit}" == "rhel"
# Red Hat Enterprise Linux 3: XFree86 + openmotif
%if "%(expr %{__distvers} '<' 4)" == "1"
BuildRequires: openmotif-devel, XFree86, XFree86-devel
%define xmkmf /usr/X11R6/bin/xmkmf
%define x11bindir %{_prefix}/X11R6/bin
%define appdefdir %{_prefix}/X11R6/lib/X11/app-defaults
%define x11mandir %{_prefix}/X11R6/man
%endif
# Red Hat Enterprise Linux 4: X.org (monolithic) + openmotif
%if "%(expr %{__distvers} '=' 4)" == "1"
BuildRequires: openmotif-devel
%define xmkmf /usr/X11R6/bin/xmkmf
%define x11bindir %{_prefix}/X11R6/bin
%define appdefdir %{_prefix}/X11R6/lib/X11/app-defaults
%define x11mandir %{_prefix}/X11R6/man
%endif
# Red Hat Enterprise Linux > 4: Modular X + openmotif
%if "%(expr %{__distvers} '>' 4)" == "1"
BuildRequires: openmotif-devel, xmkmf, libXmu-devel, libXpm-devel
%define xmkmf /usr/bin/xmkmf
%define x11bindir %{_bindir}
%define appdefdir %{_datadir}/X11/app-defaults
%define x11mandir %{_mandir}
%endif
%endif
# Fedora Core
%if "%{__distinit}" == "fc"
# FC 1..2: Monolithic XFree86 + openmotif
%if "%{__distvers}" == "1" || "%{__distvers}" ==
"2"
BuildRequires: openmotif-devel, XFree86-devel
%define xmkmf /usr/X11R6/bin/xmkmf
%define x11bindir %{_prefix}/X11R6/bin
%define appdefdir %{_prefix}/X11R6/lib/X11/app-defaults
%define x11mandir %{_prefix}/X11R6/man
%endif
# FC 3..4: Monolithic X.org + openmotif
%if "%{__distvers}" == "3" || "%{__distvers}" ==
"4"
BuildRequires: openmotif-devel
%define xmkmf /usr/X11R6/bin/xmkmf
%define x11bindir %{_prefix}/X11R6/bin
%define appdefdir %{_prefix}/X11R6/lib/X11/app-defaults
%define x11mandir %{_prefix}/X11R6/man
%endif
# FC5: Modular X + openmotif
%if "%(expr %{__distvers} '=' 5)" == "1"
BuildRequires: openmotif-devel, xmkmf, libXmu-devel, libXpm-devel
%define xmkmf /usr/bin/xmkmf
%define x11bindir %{_bindir}
%define appdefdir %{_datadir}/X11/app-defaults
%define x11mandir %{_mandir}
%endif
# FC6 onwards: Modular X + lesstif
%if "%(expr %{__distvers} '>' 5)" == "1"
BuildRequires: lesstif-devel, xmkmf, libXmu-devel, libXpm-devel
%define xmkmf /usr/bin/xmkmf
%define x11bindir %{_bindir}
%define appdefdir %{_datadir}/X11/app-defaults
%define x11mandir %{_mandir}
%endif
%endif
...
%files
%defattr(-,root,root,-)
%doc README
%{_datadir}/applications/*.desktop
%{x11bindir}/mgdiff
%{appdefdir}/Mgdiff
%doc %{x11mandir}/man1/mgdiff.1x*
Paul.
8:07 a.m.
On Wed, 17 Dec 2008, Number Cruncher wrote:
As a developer for a small ISV selling engineering analysis software
(www.cambridgeflowsolutions.com), I'm responsible for packaging our
software into RPMs for clean installation anywhere from e.g. RHL7.3,
SUSE 9, to RHEL5, Fedora 10, and SLES10.
RHL7.3? Congratulations, I managed to move _all_ my customers away from
that. Even though it was _the_ rock stable enterprise operating system.
5 years uptime and counting on some of these boxes. :)
This stuff really matters to me - I've spent many days tearing my
hair
out with build-related issues. At present, we've a single spec file with
many %if clauses to handle all the different package naming conventions
on SUSE/RedHat over time. There are 60 lines just to select the right
X11 BuildRequires.
I fear however, that buildsystem synchronisation is not really going to
help you very much. What you're looking for is more something like United
Linux and we all know how that fared.
In theory, this single source RPM should then build on either
buildsystem. We can't release our source to a public buildsystem, so I
run mock 0.7.2 in-house with some custom buildgroups and buildsys-macros
which I have to maintain to populate the initial chroot.
Doesn't sound like a bad idea. Many companies are running their in house
builders on mock.
Trouble is the latest mock (0.9.13) won't build my SUSE-related
RPMs
(hangs on some file descriptor during chroot construction). And the SUSE
buildsystem isn't as easy to install locally as mock, so I can't use
that without spending many more days....
Bug. check the debug output.
Every time a new release arrives from a major Linux distributor, I
have
to spend hours trying to cajole my old mock builder to work with it.
Personally, I find these %if %endif-ed specs for a bunch of distros
horrible to read.
including Buildreqs etc. from other files might make that easier to read,
but it's a hackish solution nevertheless.
regards,
andreas
8:50 a.m.
Andreas Thienemann wrote:
> software into RPMs for clean installation anywhere from e.g.
RHL7.3,
> SUSE 9, to RHEL5, Fedora 10, and SLES10.
RHL7.3? Congratulations, I managed to move _all_ my customers away from
that. Even though it was _the_ rock stable enterprise operating system.
5 years uptime and counting on some of these boxes. :)
I know. The problem is that
the bigger they are, the slower they move...
I fear however, that buildsystem synchronisation is not really going to
help you very much. What you're looking for is more something like United
Linux and we all know how that fared.
Okay, I can just about live with the messy spec files. I can't expect to
retrospectively patch rpmbuild back to RHL7.3... But from .src.rpm
onwards, a unified build approach would be so much simpler.
Doesn't sound like a bad idea. Many companies are running their in house
builders on mock.
Personally, I find these %if %endif-ed specs for a bunch of distros
horrible to read.
including Buildreqs etc. from other files might make that easier to read,
but it's a hackish solution nevertheless.
I think the mock buildsys-build approach could be extended and
simplified to help here. At the moment it provides the bare minimum RPMs
needed by *every* build and saves cluttering every spec file with
BuildRequires: bash coreutils, etc., etc..
If OS vendors agreed a common RPM capability naming system along LSB
lines, then provided buildsys-build-capability packages for all of their
OS, an ISV could then just require that virtual capability and let the
builder deduce the BuildRequires.
E.g.
buildsys-build-x11-development.noarch.rpm, Provides: x11-development,
Requires: libXrender-devel, libXrandr-devel.. (RHEL5 .noarch.rpm version)
Requires: XFree86-devel (Fedora Core 2 .noarch.rpm version)
Requires: xorg-x11-devel (OpenSUSE 10.1 version)
My .src.rpm:
BuildRequires x11-development
5621
days inactive
5622
days old
buildsys@lists.fedoraproject.org
10 comments
7 participants
participants (7)
-
Andreas Thienemann -
Dennis Gilmore -
Michael Schwendt -
Mike McGrath -
Number Cruncher -
Paul Howarth -
Till Maas