On Wed, Oct 10, 2018 at 3:15 PM Matthew Miller <mattdm(a)fedoraproject.org> 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