SCL discussion at yesterday's meeting: Branches
by Toshio Kuratomi
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
10 years, 5 months
- 3
- 4
SCL discussion at yesterday's meeting, Filesystem location part 2
by Toshio Kuratomi
In addition to the straw poll on /usr vs /opt we also noted that no matter
whether /usr or /opt was used, config files would still need to be placed
somewhere under /etc and state files somewhere under /var. At the meeting
we decided that /$dir/scl/$scl_name subdirs would be preferable to renaming
individual config files (see the meeting log for raionale). We discussed
something like this:
* /etc/scl/$scl_name
* It was noted that an /etc/scl is alread a directory for scl-utils. I'm
unsure if we should simply reuse that directory, have a subdirectory of
that, or use a different subdirectory name in /etc/.
* /var/lib/scl/$scl_name (at the meeting we discussed /var/scl but I think
is more FHS consistent and has the same impact)
* This would contain a filsystem tree similar to /var/ with the exception
of /var/log
* /var/log/scl/$scl_name
* This is not set in stone but we tentatively thought that sysadmins would
be very thankful if we made sure log files continued to land in /var/log
instead of making them hunt for them in a bunch of different
/var/lib/scl/$scl_name/log/ trees.
I don't see any oher way around doing this as the needs of config files and
state files pretty means they have to live under those directory trees but
I'm sending this as a separate email as it does involve a change from what
current scls are doing so people might want to discuss this separately from
the "easy decisions" made yesterday.
-Toshio
10 years, 5 months
- 1
- 0