#5894: git branches for SCL packages

[Fedora Release Engineering]

#5894: git branches for SCL packages
------------------------------+-----------------------
  Reporter:  mmaslano         |      Owner:  rel-eng@…
      Type:  task             |     Status:  new
 Milestone:  Fedora 21 Alpha  |  Component:  git
Resolution:                   |   Keywords:
Blocked By:                   |   Blocking:
------------------------------+-----------------------

Comment (by toshio):

 @mattdm: A FAD is a fine idea.  There have been FADs for packaging of many
 sets of packages.  (The CMS that docs was looking at using, the Merge
 Review FAD that dgilmore is presently looking at doing, etc).

 The re-review for rename is a good example.  You can take it as a lower
 boundary on changes that require a new review. (there could be an even
 lower boundary -- but none has ever been presented to fesco).  There are
 many more changes needed to create an scl version of a package than the
 changes to create a package rename.  More of those changes are totally new
 to the package maintainer (for a rename, the only change that they likely
 haven't encountered before is the Obsoletes/Provides additions.  For SCLs,
 there are many things not encountered outside of SCL packaging.  For
 example, Addition of %_scl_prefix, filtering of autoprovides and
 autorequires, manual specification of dependencies on things that rpm
 autodeps would pick up in a non-scl package, changes to the install dir
 macros and when to use the %root_*dir macros instead of the scl overridden
 ones.)

 The effect of failure is also slightly higher here than in the rename
 case.  When a package rename does obsoletes and provides wrong it
 generally means that the renamed package fails to remove the pre-rename
 version of that package.  In many cases, the end users' systems continue
 to function in that case but the package in question stays at the old
 version until someone realizes the provides and obsoletes need to be
 adjusted.  For SCLs, getting things wrong means that the SCL could replace
 a system package or a system package could replace an SCL.  Either one
 will lead to breakage of apps which depend on the other version of that
 package.

 Other examples that we could take a look at in increasing order of
 difference from the already reviewed package are:

 * parallel installable packages: (python3, gtk2/gtk3, python-mako0.4)
 these currently undergo new package review.
 * mingw packages: these currently undergo new package review.  This is
 also the most comparable to what SCLs do so we likely would want to
 revisit whether reviews are needed for parallel installable and mingw
 packages if we say that reviews are not needed for SCLs.
 * Forks of existing packages: (libreoffice, icecat, etc) these currently
 undergo new package review.  In some cases, the forks remain very close to
 what we previously had.  In other cases they quickly diverge.

 As for fesco ticket -- I'm not sure -- it's in the grey area between FPC
 and FESCo.  I think it's probably a "what to package" question rather than
 a "how to package" question so it probably belongs to fesco.  However, FPC
 has been assuming that the packages would undergo new package review as
 normal (we've talked about which things in the guidelines would belong
 with reviewing of the SCL for approval vs which things would belong in the
 review of the packages themselves) so we might want to have a
 recommendation from the FPC.  From previous discussions close to the
 topic, though, I think they're likely to recommend that the packages
 undergo new package review.

 @pfrields: Having created SCLs, the differences between the non-SCL and
 the SCL packages are non-trivial and prone to errors.  Someone fluent in
 creating non-SCL packages will have to learn a large amount of new
 information in order to create a proper SCL.  Two separate python modules
 have spec files that are more similar than an SCL and non-SCL version of
 the same and the knowledge that applies to one python module will carry
 over to the other python module whereas the knowledge of how to create an
 SCL is in addition to the knowledge needed to create the python module.

 The license, checksums, and other factors do change as well.  Just last
 month people on devel list were complaining that packages don't get
 reviewed once they are built.  New upstream releases are just as likely to
 introduce changes that break licensing, require new dependencies,  For
 SCLs we're very deliberately shipping separate upstream versions of
 software to our users.  Different build dependencies, different build
 flags, different included files, different installed files, or even
 different build scripts will come into play with these different versions.
 Since we already need to review the packages for the changes that being an
 SCL introduces, we will also be able to review to catch these issues as
 well.


 The example SCL in the documentation is a simplistic case (it's also
 wrong.  The less.sh and less.csh files are configuring bash, not less.
 Therefore they have to be renamed and placed in
 %{_root_sysconfdir}/profile.d/ rather than in the SCL's private
 %{_sysconfdir}.  The example also doesn't make clear that the code inside
 of less.sh and less.csh has to be modified from the non-SCL package [If
 you take a look at /etc/profile.d/less.sh on your system, you'll see that
 it hardcodes /usr/bin/lesspipe.sh and sets an env variable.  The SCL
 version would need to detect the lesspipe from the SCL.  There would have
 to be some thought put into how to handle the env variable.  Perhaps, the
 upstream code would have to be patched to use a different env var.
 Perhaps the env var could be set to lesspipe without a full path (so that
 if the user scl enabled the less SCL then they would get the SCL lesspipe,
 otherwise they would get the non-scl lesspipe) See why SCL packages should
 get reviewed? ;-)  Here's a diff between an scl and non-scl version of
 python2.4 to show some of the other issues that could arise with SCLs:
 http://toshio.fedorapeople.org/scls/python-scl.diff

-- 
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5894#comment:17>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project