Hi Adam! On Tue, 2019-11-05 at 15:24 -0800, Adam Williamson wrote: > This has a few consequences I can think of. For a start it means the > actual problem we're currently having with our current module streams > wouldn't necessarily be solved by your system - we could've run into > exactly the same problem, more or less; the libgit2 package could've > declared a '0.27' stream in F29 and then decided that in F31 it > wanted > everyone on the '0.28' stream, or something like that. We still have > the potential problem of needing to define rules and implement > mechanisms for stream transitions at release boundaries, essentially. Yeah agreed, there does need to be a way to express what to do upon release boundaries. Though Gentoo does not have releases, they do still have "slots" that go from being "supported" to being unsupported (which is to say, dropped from the repository). I personally think this is somewhat similar to "upgrading from F29 to F31", with the obvious exception that in Gentoo there isn't a coordination point for *when* packages will do this. This means that on any given day, you could find out that the stream you are using is gone now. That's part of the fun of Gentoo! (I'm not saying we should do that). In Gentoo, when a package goes from supported to unsupported, you are going to have to switch to a supported slot/stream. Typically, the package manager does this for you (and it has notation on the upgrade command that shows you that you are switching slots so you can be informed.) Sometimes there can be conflicts, but I think "more conflicts" is just one of the consequences of allowing different packages to require conflicting dependencies (not every package in Gentoo is parallel installable, so you can hit conflicts this way.) I agree with you that "we have to decide what to do" is true here too. I think that having this one problem in common is OK though, given that I think it will be easier for our packagers to make use of it. > Another one - how does this work on the packaging end? Do I have some > sort of combinatorial explosion of dist-git branches for > "release+stream", so that if I introduce a stream called 'foo' I get > an an f29-foo git branch, an f30-foo git branch, an f31-foo git > branch and a master-foo git branch? Then I get another four branches > for each new stream? And each time a release comes out I get X new > branches, where X is the amount of streams that exist? Or would there > be another way to do it? Yeah this is a great question. I do think this problem is the same for modularity as it is for what I'm suggesting too, like the above problem. It's just that it splits the combinatorics between two dist- git repos instead of one. I can think of a few ways. I've actually been thinking about how our dist-git works a lot lately, and have some thoughts. So we could keep doing what modularity has done, where the branch names are the streams, and not Fedora versions. You don't strictly have to build a Fedora package from the given release today. I (rarely) have built the master branch for a stable release, because the spec file had nothing in it that was special for any particular Fedora version. So we could just have stream names as the branches, just like modularity already did, and then just point Koji at it with the build target you want (to get the matrix of Fedora versions). Or, we could do things more differently! In Gentoo, their spec files are called ebuilds, and you just put n ebuilds in the repo at a time, corresponding to the version of the package that the ebuild is for. Now, this results in some copying, which is certainly a drawback, but you could imagine naming the spec file with the stream as part of it or something like that. Here's an example: https://github.com/gentoo/gentoo/tree/master/dev-lang/python Or we could go crazy on the combinatorics with the stream and Fedora version, like you hinted at above (prob not ideal). Here's a neat idea though: there was also a thread a month or three ago where Jeremy Cline suggested using git tags to indicate the version, release, and even user facing update notes (in the tag message body). What if we extended that idea to also allow notating the stream and Fedora/EPEL version in the tag? Then, the meaning of the branches is completely up to the packager - they can devise a branching strategy that works for them, as they see fit, and they just tag certain commits, in any branch they please, with the FNESVR (Where F is the Fedora/EPEL version) that they want to turn that commit into. For packagers who want to put the same spec file in all branches today (I think Kevin Koffler often likes to do this), they can just maintain a master branch and not bother with all the merging, and just add a few tags to indicate the releases they want to go out. For packagers who are maintaining pretty divergent spec files for different Fedora/EPEL versions, or divergence due to streams, they can make the branches that make sense to them to help manage that complexity.
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
