Fellow Haskell Hackers, the d:l:h:lts:6 project contains a set of builds for the Haskell packages in Stackage LTS 6.x (plus additional ones) that is completely auto-generated. Whenever a few Stackage release comes out, we can basically say "make update all" and then we'll have an updated project. Manual maintenance is required only to fix build failures that might occur, of course, because of missing system libraries, etc. Since the automatic generation allows us to maintain the package set more reliably, we'll merge our efforts from d:l:h:lts:6 into d:l:h, which is still the proper development project for Factory. We'll continuously run that synchronization in the future, but the first time we copy things over is a somewhat delicate operation because d:l:h contain manually made modifications to the spec files that d:l:h:lts:6 did not contain. Some of those modifications are vital for the package's functionality and should not be lost. Other modifications are unimportant or purely cosmetic and can be dropped. In this first-time merge, we'll create almost 2000 submit requests that we'll need to review and approve. Once we've been through this, subsequent mergers will be very simple, i.e. fully automatic. Anyway, as an example, consider the SR for the package "shake": | old: devel:languages:haskell/shake | new: devel:languages:haskell:lts:6/shake rev 5 | Index: shake.changes | =================================================================== | --- shake.changes (revision 10) | +++ shake.changes (revision 5) | @@ -1,4 +1,9 @@ | ------------------------------------------------------------------- | +Sun Jul 10 17:23:20 UTC 2016 - psimons@suse.com | + | +- Update to version 0.15.10 revision 0 with cabal2obs. | + | +------------------------------------------------------------------- | Wed Jun 15 09:23:40 UTC 2016 - mimi.vx@gmail.com Auto-generated packages get a change log entry like this one. The makefile adds such an entry if -- and only if -- the string "version x.y.z revision v" is *not* found in the change log file already. The revision number of the package refers to the revision on *Hackage*. That's not the same thing as the revision number our RPMs have, which is auto-generated by OBS. These two are unrelated. On some occasions, we've edited a pre-existing change log entry to state the version number in that format to prevent the auto-generator from adding a new one, but this happened only rarely. These are all trivial changes that mean nothing: | --- shake.spec (revision 10) | +++ shake.spec (revision 5) | @@ -1,7 +1,7 @@ | # | # spec file for package shake | # | -# Copyright (c) 2015 SUSE LINUX GmbH, Nuernberg, Germany. | +# Copyright (c) 2016 SUSE LINUX GmbH, Nuernberg, Germany. | # | # All modifications and additions to the file contributed by third parties | # remain the property of their copyright owners, unless otherwise agreed | @@ -18,19 +18,15 @@ | | %global pkg_name shake | %bcond_with tests | -Name: shake | +Name: %{pkg_name} | Version: 0.15.10 | Release: 0 | Summary: Build system library, like Make, but more accurate dependencies | -Group: Development/Languages/Other | - | License: BSD-3-Clause | +Group: Development/Languages/Other | Url: https://hackage.haskell.org/package/%{name} | Source0: https://hackage.haskell.org/package/%{name}-%{version}/%{name}-%{version}.tar.gz | -BuildRoot: %{_tmppath}/%{name}-%{version}-build | BuildRequires: ghc-Cabal-devel | -BuildRequires: ghc-rpm-macros | # Begin cabal-rpm deps: | BuildRequires: ghc-binary-devel | BuildRequires: ghc-bytestring-devel | @@ -41,15 +37,16 @@ | BuildRequires: ghc-hashable-devel | BuildRequires: ghc-js-flot-devel | BuildRequires: ghc-js-jquery-devel | -BuildRequires: ghc-time-devel | BuildRequires: ghc-primitive-devel | BuildRequires: ghc-process-devel | BuildRequires: ghc-random-devel | +BuildRequires: ghc-rpm-macros | BuildRequires: ghc-time-devel | BuildRequires: ghc-transformers-devel | BuildRequires: ghc-unix-devel | BuildRequires: ghc-unordered-containers-devel | BuildRequires: ghc-utf8-string-devel | +BuildRoot: %{_tmppath}/%{name}-%{version}-build | %if %{with tests} | BuildRequires: ghc-QuickCheck-devel | %endif | @@ -84,10 +81,10 @@ | %package -n ghc-%{name}-devel | Summary: Haskell %{name} library development files | Group: Development/Libraries/Other | +Requires: ghc-%{name} = %{version}-%{release} | Requires: ghc-compiler = %{ghc_version} | Requires(post): ghc-compiler = %{ghc_version} | Requires(postun): ghc-compiler = %{ghc_version} | -Requires: ghc-%{name} = %{version}-%{release} | | %description -n ghc-%{name}-devel | This package provides the Haskell %{name} library development files. | @@ -103,31 +100,38 @@ | %install | %ghc_lib_install Note that all our generated spec files are automatically run through spec-cleaner to guarantee a consistent look and feel. As a result, some attributes will have switched positions compared to the spec files we have in d:l:h. | -rm -Rf docs/manual | -rm -Rf %{buildroot}/%{_datadir}/%{name}-%{version}/docs Now, here comes a significant change. Generally speaking, installing docs is good and we should not remove them. In this particular case, however, we'll see that the docs end up being installed twice in two separate locations and that's not good. You'll see more below. First comes more trivial stuff: | %check | %if %{with tests} | -%cabal test | +%{cabal} test | %endif | | | %post -n ghc-%{name}-devel | %ghc_pkg_recache | | - | %postun -n ghc-%{name}-devel | %ghc_pkg_recache | | - | %files | %defattr(-,root,root,-) | %doc LICENSE | %doc README.md docs | %{_bindir}/%{name} | -%{_datadir}/%{name}-%{version} | +%dir %{_datadir}/%{name}-%{version} | +%dir %{_datadir}/%{name}-%{version}/html | +%dir %{_datadir}/%{name}-%{version}/docs | +%dir %{_datadir}/%{name}-%{version}/docs/manual | +%{_datadir}/%{name}-%{version}/html/viz.js | +%{_datadir}/%{name}-%{version}/html/profile.html | +%{_datadir}/%{name}-%{version}/html/progress.html | +%{_datadir}/%{name}-%{version}/html/shake.js | +%{_datadir}/%{name}-%{version}/docs/manual/build.bat | +%{_datadir}/%{name}-%{version}/docs/manual/Build.hs | +%{_datadir}/%{name}-%{version}/docs/manual/build.sh | +%{_datadir}/%{name}-%{version}/docs/manual/constants.c | +%{_datadir}/%{name}-%{version}/docs/manual/constants.h | +%{_datadir}/%{name}-%{version}/docs/manual/main.c Note that these explicit %file sections are auto-generated by the new cabal-rpm tool. These %file specs can be relied on to be correct. One thing we must watch our for, however, is that sometimes %doc contains the same content as %datadir. | %files -n ghc-%{name} -f ghc-%{name}.files | %defattr(-,root,root,-) | @@ -135,6 +139,6 @@ | | %files -n ghc-%{name}-devel -f ghc-%{name}-devel.files | %defattr(-,root,root,-) | -%doc README.md | +%doc README.md docs | | %changelog These changes look a little suspicious. Apparently, the docs hierarchy is included in both the main and the -devel package? Furthermore, it looks like the manual is installed in both %datadir and as %doc. We prefer it to be in %doc, so apparently we should have kept the "rm" commands we have seen in the diff above. As is, this SR should be flagged and probably refused. All manually created changes to the spec files are recorded in patch files at https://github.com/opensuse-haskell/configuration/tree/master/patches and the build process applies those changes automatically after running cabal-rpm, so we can influence the generation process in any way we please. On the other hand, we generally have no love for manual changes, because these patches create more work for us. They are hard to maintain and to keep up-to-date. So as a rule of thumb, I'd recommend being somewhat liberal with the generated files because auto-generating 2000 builds is no fun of we end up having 2000 patches on top-of them. :-) In some cases, it's preferable to try and improve the upstream Cabal file or the cabal-rpm utility. Best regards, Peter -- To unsubscribe, e-mail: opensuse-haskell+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-haskell+owner@opensuse.org