Hi Peter, Peter Schaffter wrote on Tue, Dec 18, 2018 at 01:41:45PM -0500: > On Tue, Dec 18, 2018, Ingo Schwarze wrote: >> Peter Schaffter wrote on Mon, Dec 17, 2018 at 08:55:04PM -0500:
>>> I've updated mom-2.4.tar.gz on mom's website, >> Never change tarballs after they are released. >> That causes bad trouble to downstream packagers: > The tarballs aren't, and never have been, for packagers. If you publish a release of some free software, whether or not it will be packaged is a downstream, not an upstream decision, and policies about what to package, what not to package, and how to structure packages are considerably different among operating systems and package management tools. However, changing published releases after the fact is likely to cause trouble for all these systems, and even more so for users getting it directly from your website. How are users supposed to know what they have is buggy if you don't bump the version number and don't announce a new release? Publishing a software release and then saying "it shall not be packaged" is akin to publishing a book and then saying "it shall not be sold in bookstores, you can only get it directly from me". Whether or not bookstores carry it is not your decision. > The "distinct from groff" nature of mom development means that > any "packaged" version will be the one from contrib/mom when groff > is built. Tarballs are posted so users can update mom without > having to pull groff from the development branch. Many packaging systems strongly discourage users from attempting to update *parts* of packages they have installed, circumventing the packaging system, because that defeats the whole purpose of having a packaging system in the first place. > The two (i.e. contrib/mom and the tarballs) are always in synch, > but packagers are not expected to use the tarballs, and indeed, > none have. If i were aware of even a single user of mom on OpenBSD, i certainly would. There are two ways to do it, both trivial: Either comment out the files contained in the mom tarball from the groff packing list and make a separate package which depends on the latest groff release. That's the more conventional way, but it has the downside that users must install the mom package in addition to groff if they want to use it. Or add the mom tarball as a second distfile to the groff port and bump the groff packaging version (in this case, from groff-1.22.3p12 to groff-1.22.3p13) when there is a new mom release. In this particular case, that's probably what i would do, because it is better that every groff installation includes mom out of the box, and there is no harm in bumping the groff packaging version when there is a new mom release. Either variant would profit from proper mom version numbering. > Every once in a while, as presently, mom presents a bug whose fix > is so small that it doesn't warrant a version change That's one thing third digits in the version string are widely used for. > but does need > to be made available to run-of-the-mill users immediately. A patch > applied to version N.N rather than a release of version N.N-x, as it > were. In such cases--extremely rare--the patch is applied to the > development branch of groff/contrib/mom and the "users' tarball" > is silently updated. Since no one is packaging mom for shipment > separately from groff, concerns about downstream packaging aren't > relevant. > > Mom began life entirely separate of groff because of groff's > slow release cycle. I got a couple of requests from Debianites > wanting to package her, and a proposal from Werner that she become > part of groff. I chose the latter despite the headache of the > groff-packaged version perpetually lagging behind the latest mom > release, a problem solved by posting the tarballs. Though mildly > unconventional, this pragmatic solution has worked without a hitch > for over ten years. Even if unpackaged, keeping bugs secret still harms your users. But i admit that the discussion about packaging requirements can be postponed until some system actually packages mom, if you prefer to not bother with it now. Yours, Ingo
