Axel Thimm wrote:
You're missing the point. If a package is only updated e.g. once a
year,
So you know beforehand how often a package will be updated in the
future?
For every package I maintain, I am able to give you a reasonable
estimate yes. For new packages, I am able to also give you a reasonable
guess based on the interaction I have with upstream for new packages and
looking at project history. I think all maintainers should have a very
good idea of how often releases are made.
and that one update is only for e.g. glibc ABI changes -- guess
what, ABI in a release (Zod, Moonshine, etc) isn't changing
Not true, for Zod -> Moonshine this was a first timer. And had gcc 4.2
landed in the usual timeframe (was expected around December) we
wouldn't even be talking about rebuilds. gcc 4.2 which is now almost a
month old will most probably make it into F8 very soon.
so there's no need to rebuild that. Just bump in rawhide and
rebuild there. disttag doesn't gain you anything here in the
branches.
Let's revert the question: "Why is it better without a disttag, out of
curiosity?". There is definitely a gain with a disttag, one can argue
how big it is, but what are the drawbacks? That some packages give
away their age? I see that as a feature, not a bug: "Hey, bridge-utils
is broken on F7. Hm, it has an fc6 marker. OK, it was built on FC6's
kernel-headers from 2.6.18, no wonder it doesn't know anything about
2.6.21"
I honestly don't care one way either way about the disttag. I use it,
but I never had the pain that other people had, and I've had to deal
with packaging all the way back to RHEL2.
But one of the arguments being made is that rebuilds should be done to
avoid old disttags in newer releases. I think that's silly. If there's
a package that doesn't need a rebuild, it doesn't need a rebuild.
Enforcing once due to disttags is a dumb idea, IMO[1]. If people are
going to enforce the "if your package has a disttag, it must get
rebuilt" rule, I'd just start using less disttags.
[1] Actually, I think we shouldn't necessary show the RPM release number
by default to the user in e.g. the installer. The average user doesn't
know what half+ the things they are installing are anyway, let alone
whether the numbers after it mean it's new or old. And if we can avoid
it in places such as pirut/pupplet by default (I imagine some people
might want to turn it on and we could perhaps offer that) then I think
that would be a win, too and would help combat the "omg, i thought this
was fc7 not fc6 lol" general sentiment.
--
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
