I should say that although I've made a few RPMs I'm not as experienced
as you guys clearly are. For example, I'm not clear on the use of a web
counter that you're talking about. Are you talking about that as a
build-time counter or some sort, or something that happens at install time?
I wanted to clear up the reason for my original question -- perhaps it
has a bearing on this. I've got a package which builds using gcc and
gfortran. gfortran comes in two different versions on the two distros
FC4 and FC5, so if I want to distribute out package I must have separate
builds for each distro (although I would like to one distribute one
.src.rpm if possible). It gets worse: the software builds with the FC4
version of gfortran, but not on the newer version (it crashes). So the
only solution I could think of was to build on FC4 and then install on
FC5 along with the libgfortran.so.0 file it depends on. I could either
create a new (separate) RPM that just contains the older libgfortran, or
I could just include the file inside my package (and add a "Provides:
libgfortran" tag of some sort, perhaps). I was thinking that I would use
an %if statement inside my .spec file that would test which distro I was
building for (either using the 'dist' variable, or perhaps using "--with
bundled_gfortran") and depending on which one it was, either include
libgfortran in the RPM or not.
This probably seems like insanity to you guys: what's the right way out?
Cheers
JP
Axel Thimm wrote:
>On Sat, Jul 29, 2006 at 05:11:56PM -0400, Jeff Johnson wrote:
>
>
>>>Seriously Jeff, it works, and the alternative of having web-counters
>>>just isn't. Why haven't we package monkeys used a web-counter? Are we
>>>that stupid? Obviously you think so.
>>>
>>>
>>"Works" how? You have never defined the goal of adding %{dist} and
>>so its impossible to tell what the goal of adding %{dist} without
>>asking someone what it means.
>>
>>
>
>Of course it was defined. It was given previously in this thread and
>it's about allowing the same set of binary packages built from the
>same src.rpm on different releases of a distro to respect the desired
>upgrade path. I thought that was clear, even the OP's subject is
>rather self-explaining.
>
>
>
>>That is a branding, not and engineering issue.
>>
>>Sure adding %{dist} is cheap advertising for various political entities.
>>
>>
>
>I'm sorry, but I'll remain on the engineering floor. Not sure who
>would even want to abuse that for political or branding issues, and I
>don't care either. I merely look at the technical demand which is
>one-specfile-for-all-releases and seek (and find) a solution within
>the given constraints.
>
>
>
>>Do the majority of packages built with
>> %define dist fc4
>>"work" on a system that chooses to identify itself with
>> %define dist fc5
>>
>>Quite likely. That's the engineering, not the branding, truth.
>>
>>
>
>You probably miss the point of disttags. The is never ever a %define
>disttag <something> in the specfile. This would defeat the whole
>purpose. The specfile is to be kept as release/distro agnostic as
>possible. The disttag is something tagged onto the package from its
>external environment (where the binary package is built in) to place
>it into the proper upgrade path.
>
>And just to make sure that wasn't lost in the discussion: The disttag
>is also not to be abused for identifying features of the
>environment/release. The purpose is well-defined as *solely* for
>ensuring proper upgrade paths.
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Rpm-list mailing list
>Rpm-list@xxxxxxxxxx
>https://www.redhat.com/mailman/listinfo/rpm-list
>
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
