On Sat, 2007-01-06 at 12:49 +0100, Michael Schwendt wrote: > On Fri, 05 Jan 2007 23:41:44 -0800, Toshio Kuratomi wrote: > > > Right. I think in this case the first thing I'd want to know is what > > does hardcoding a disttag buy you that not having a disttag at all does > > not? With that information, a more informed decision could be made. > > Hardcoding a dist tag explicitly flags the package as being made for that > dist by the packager. That is visible in the file name, too. > It's visible in the file name when something's wrong (ie: 1.fc4 in the devel tree). It blends in when everything's right. (As it should.) > 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? -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- 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
