mpeters@xxxxxxx ("Michael A. Peters") writes:
> On Wed, 2006-01-11 at 19:50 +0100, Simon J Mudd wrote:
>
> >
> > Please note that most people make the release of the form
> >
> > Release: 1.%{distro}
> >
> > not as described above.
>
> It's better to do 1%{?dist} imho
> with the . as part of the %{dist} macro (if defined)
Agreed.
> I don't know how other distributions do things, but the mock (and
> previously mach) build environments for Fedora Extras define the dist
> macro. It's not defined in the standard rpm macros, but it is in the
> chroot build environments.
The problem with this and for example the dag rpm repository is that
you have to manually add/set the macro for things to work. That's not clean.
It should be automatic as different RPM repositories do things differently.
> I would not be opposed to an official macro name in LSB to use for that.
That would be good and if necessary an (very) simple rpm could provide
the check for that, an rpm which is vendor neutral and provides the
script/macro required to correctly recognise as many distributions as
possible.
> I would be opposed to LSB stating that packages need a %{?dist} - I
> don't think that is always necessary.
Again I agree. This facility is for third party packagers who want to
build rpms for multiple vendors and/or distributions. The main reason
for adding the %{dist} macro to the end of the Release: tag is to
avoid writing multiple binary rpms into the same location when
building/storing AND to enable us to recognise them after having been
built. As such these rpms are ALWAYS add-on packages and never part
of the distribution itself.
Is that reasonable/sensible?
> As far as distributions setting the macro, that really only needs to be
> done in the build environment (which should be used for packages meant
> for distribution to avoid accidental linkage against unintended
> libraries/versions of libraries)
This is precisely the point. The libraries compiled/linked
against change from one version of a distribution to another and this
MUST be taken into account when building a third party rpm.
The DB library is one hellish example.
This macro is really a "helper" macro for external developers to help
them/us build for multiple distributions in a standard and consistent
manner. It would also be nice to have a recommended way of integrating
with the distribution RPMs in a way which does not cause conflicts.
Agreeing on a commmon practice as to how to do this would save us all
time as it allows new third party rpms to be built consistently and
the checks to be in place to build them correctly.
The more distributions you try and support the worse this gets.
Regards,
Simon
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
