>>>>> "VO" == Vít Ondruch <vondruch@xxxxxxxxxx> writes: VO> I think FPC does not know. Certainly we know what we generally try to do, but Fedora changes quickly and some things aren't always stated as well as they could be. Plus the experts who draft the more esoteric guidelines often have other ideas. The guidelines cover everything from the oldest supported release to rawhide. Where they don't we try to indicate that. When sections get outdated, I will generally remove them (and shift them to the EPEL packaging page) but sometimes I miss something. VO> Let me quote from Ruby guidelines update [1] which initially aimed VO> on Rawhide, now it covers all supported Fedoras, I personally wasn't aware that it does. To be completely honest you were pretty argumentative about the whole issue and I personally decided to concentrate on other things and haven't gotten back to looking at it. VO> ... Actually I'm not sure why, may be because of EPEL VO> (in)compatibility? The guidelines generally aren't concerned about EPEL compatibility. I mean, when it's possible and someone proposes a reasonable solution which lets things remain compatible, I think we're all happy to consider it but the guidelines are about the current two or three Fedora releases plus rawhide. But to the question at hand, it's often simply not possible to have a "clean" spec and keep backwards compatibility all the way to EPEL. I find it surprising how much confusing conditional macro stuff people are willing to deal with just to avoid having a couple of different spec files. To me the maintenance overhead of that stuff is far greater than the work required to just maintain the specs separately, but I guess others feel differently. Even if we somehow officially discouraged some of the more hideous stuff people do in pursuit of the "everything spec", I just can't see it being banned because people like it too much. - J< _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
