Disttags are nice, save the disttags

[Christopher Aillon]

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.