On Sun, 07 Jan 2007 14:28:35 -0800, Toshio Kuratomi wrote:
> > A simple mass-rebuild would not pretend that the package has been updated
> > (read: prepared for the new dist). It would need a package maintainer to
> > update customisation and integration patches first before changing the
> > dist tag would make sense.
>
> When would this be appropriate to use?
>
> In non-devel branches it could mark where the packager made the
> conscious decision to create a separate spec file for the older release.
> In this case, it is really just a comment for other packagers to pick up
> as we don't rebranch a package after the first import.
>
> In the devel branch, it would mark the package as needing to be updated
> manually for every release and could prevent mass rebuilds from
> operating on it (or flag the package as needing more work if it were
> mass rebuilt). However, how does the packager know that this is the
> case before the new release is even created? Is there an example
> package which illustrates this?
We've had it before with custom patches (e.g. configuring an application
with different helper program paths for different distribution targets,
versioned requirements, dist-dependent build sections). We've had it
before that a previously orphaned package was picked up, extended with
%{?dist} and mass-built for multiple dists down to the oldest dists only
to find it breaks at run-time because the spec was less "portable" than
expected. I don't keep a book where I write down such issues.
All that matters is that bad experience with %{?dist} piles up.
Among the worst things is that you cannot use the dist tag in the
%changelog. You cannot keep %release and %changelog in sync, particularly
not when a minor release is added right of %{?dist} as some packagers do
it to work around cvs tagging mess.
I see the benefit of being permitted to hardcode a dist tag.
--
Fedora-maintainers mailing list
Fedora-maintainers@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers
--
Fedora-maintainers-readonly mailing list
Fedora-maintainers-readonly@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
