Prologue: Neither of these may be possible in F20. releng needs to test whether any of this is possible and figure out what work would be needed to get this to happen.
A straw poll was taken on the ideal branch layout. Unlike the filesystem location, support for the various ideals of what branches should look like was mixed. In the end, there were 4 people for having scl-ified spec files separate from mainstream packages and 1 person for giving maintainers the choice of which path to pursue but only a few people felt strongly either way (2 for separate and 1 for maintainer choice).
Here's how I presented keeping scl-ified spec files separate:
releng issues aside, the goal is to have one package for all scl versions and one package for the mainstream version. Inside of the mainstream version, there will be a branch for each fedora release (just like now). Inside the scl version, there will be a branch for each scl+fedora version combination. The master branch of the scl version will be a clone of the mainstream package master. SCL macros will only occur in the scl git, not in the mainstream git.
Here's how I presented having them combined:
They [the scl team] want to be able to have a single git repo for each package. there would be scl+fedora version branches inside of there as well as the fedora version branches for mainstream versions. the mainstream packages can have scl macros. all macros are conditionalized so that they only apply when building an scl.
A proposal was also made that each scl+package combination should get a separate package in the git repo. The rationale was that spec files would likely have to differ just by nature of upstreams changing things between versions of their upstream package. I think we'll have to discuss this more but my instinct is that we'll find that some spec files will remain the same between scls because they aren't the primary purpose that the scl is being built and thus they can both be at the same version. So it makes sense to share spec files for different scls. (Note - this is nearly identical to our fallback for F20/F21 in case releng finds that we can't do any sort of scl-in-branches without tooling changes. But I still don't think this should be the goal that we shoot for.)
So what's the impact here? If we go with a separate package for all scl work, we can remove the conditionals from the guidelines. General SCL packages will have the scl macros. Mainstream packages will not. Packagers (provenpackagers, new maintainers taking over a package, etc) won't have to worry about scl macros unless they're actually interested in the general scl packages. If we make combined our ideal then packagers who do want to shepard their package as a general SCL package and a mainstream package will be able to share changes between the mainstream and SCL packages more easily. The cons are basically the reverse of those, combined means higher barrier of entry for packagers who then have to learn about scl packaging in addition to mainstream packaging. Separate means changes in the mainstream package might take more work to prot to the general SCL package.
-Toshio
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 01/11/2013 21:13, Toshio Kuratomi a écrit :
releng issues aside, the goal is to have one package for all scl versions and one package for the mainstream version.
Just to understand correctly, what is the tooling issue ?
If this is about NEVR must being unique, we should have as much package as SCL.
I means python-foo (mainstream) scl-python26-foo scl-python27-foo scl-python33-foo
Else (1 package for all scl) we're going to have the same NVER issue.
Remi.
On Sat, Nov 02, 2013 at 10:14:20AM +0100, Remi Collet wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 01/11/2013 21:13, Toshio Kuratomi a écrit :
releng issues aside, the goal is to have one package for all scl versions and one package for the mainstream version.
Just to understand correctly, what is the tooling issue ?
Dennis has a bunch of potential issues floating around in his brain. At the last meeting we pretty much decided that he'll need time to look at what will happen if we try to do this in our staging environment. He won't have time to do that until after F20 is out and he won't have time in the F21 timeframe unless we make the F21 schedule longer. He wanted to take a stab at estimating how much time it would take before asking fesco if we could increase the schedule more.
If this is about NEVR must being unique, we should have as much package as SCL.
I means python-foo (mainstream) scl-python26-foo scl-python27-foo scl-python33-foo
Else (1 package for all scl) we're going to have the same NVER issue.
Yeah, that kinda approximates what I termed the fallback case in my email. One git-repo-package per scl+package. The normal fedora branches inside of there. Dennis says that will definitely work. I think we all agreed that that our goal should be something better than that but we may end up having to suffer through a release or two with that until we can get something better figured out.
-Toshio
On 11/03/2013 06:31 AM, Toshio Kuratomi wrote:
On Sat, Nov 02, 2013 at 10:14:20AM +0100, Remi Collet wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 01/11/2013 21:13, Toshio Kuratomi a écrit :
releng issues aside, the goal is to have one package for all scl versions and one package for the mainstream version.
Just to understand correctly, what is the tooling issue ?
Dennis has a bunch of potential issues floating around in his brain. At the last meeting we pretty much decided that he'll need time to look at what will happen if we try to do this in our staging environment. He won't have time to do that until after F20 is out and he won't have time in the F21 timeframe unless we make the F21 schedule longer. He wanted to take a stab at estimating how much time it would take before asking fesco if we could increase the schedule more.
If this is about NEVR must being unique, we should have as much package as SCL.
I means python-foo (mainstream) scl-python26-foo scl-python27-foo scl-python33-foo
Else (1 package for all scl) we're going to have the same NVER issue.
Yeah, that kinda approximates what I termed the fallback case in my email. One git-repo-package per scl+package. The normal fedora branches inside of there. Dennis says that will definitely work. I think we all agreed that that our goal should be something better than that but we may end up having to suffer through a release or two with that until we can get something better figured out.
-Toshio
-- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
I asked on internal mailing list. It looks like every project used a new branch for packages, not new dist-git. Specfiles are different, but there a new branch for it. The main reason was cherrypicking patches from other branches.
How to setup koji for scls: http://miroslav.suchy.cz/blog/archives/2013/10/09/how_to_set_up_koji_for_scl...
I didn't hear about any specific issues, so I can't tell if there are other problems or not.
Marcela
packaging@lists.fedoraproject.org
-
Marcela Mašláňová -
Remi Collet -
Toshio Kuratomi