Re: .spec file for multiple target distros

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
-- 
Axel.Thimm at ATrpms.net

Attachment: pgpsVclX7wDtQ.pgp
Description: PGP signature

_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list

[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux