On Wed, Oct 10, 2018 at 3:15 PM Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > > On Tue, Oct 09, 2018 at 06:07:44PM -0600, Al Stone wrote: > > -- And the one question I have to add on to Christopher's wonderful > > list: I have a package where upstream releases about once a month, > > and each new release must by definition be backwards compatible > > (acpica-tools, specifically). I can think of no scenario where a > > module provides value to me or end-users; in fact, using anything > > other than the most recent causes problems. Do I have to create and > > maintain a module for this package anyway? Or are the defaults > > robust enough that a package can remain a package without touching > > modularity at all? The answer to this is completely unclear to me -- > > what I've read seems to imply that I must create a module definition > > regardless. > > > This actually seems like the ideal case for a single stream -- instead of > maintaining rawhide, f29, f28, epel7, you'd just maintain "latest", > and that would get build into all of these releases simultaneously. What is the overhead of maintaining a module for a single package, plus the package itself, vs just maintaining the package the current way? My understanding-- from skimming the documentation a few times and reading discussions about modularity-- is that I'd now need to keep track of two dist-git repositories, and two different metadata files. This feels like a lot of extra overhead. It also requires learning about a new thing-- modulemd files. Is this really less work? I admit I haven't tried to do it myself yet, so I don't know. But part of the reason I haven't tried it is because I'm not sure if it will actually be better... I guess it would be nice to read a sort of "modularity for the skeptical contributor" document or article that answers questions like this. Ben Rosser _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
