Hi Jason,
Because the draft was submitted to us as complete, and we voted on it.
I understood that it was submitted as a draft for comments...
If someone didn't want us to vote on it, it would have been nice if someone had let us know.
I thought that was what this discussion was about:
https://www.redhat.com/archives/fedora-packaging/2008-August/thread.html#000...
Thanks for the headsup anyway. :)
Jens
On Wed, Aug 27, 2008 at 8:26 PM, Jens Petersen petersen@redhat.com wrote:
Hi Jason,
Because the draft was submitted to us as complete, and we voted on it.
I understood that it was submitted as a draft for comments...
Long ago, i got tired of submitting drafts for comments to have to wait. I took spot's advice and just submitted them for review and comment simultaneously. The principle idea was that I put a deadline on the commenting period, and if there were no comments by a certain time, then it would go straight to review. This way, two groups of people got a chance to look at the drafts at the same time.
Finally, it went for a review by the Committee, and they made their comments. We also discussed your comments. I addressed their comments, which was the final request for review.
Like I said (accidentally offlist), it's not set in stone either, I'm still listening.
-Yaakov
Frankly, I think that the current version of the guidelines is fine. It's much better to have something not quite perfect where we can make progress than to be permanently stuck. So moving forwards with what we have suits me.
On 8/27/08, Yaakov Nemoy loupgaroublond@gmail.com wrote:
On Wed, Aug 27, 2008 at 8:26 PM, Jens Petersen petersen@redhat.com wrote:
Hi Jason,
Because the draft was submitted to us as complete, and we voted on it.
I understood that it was submitted as a draft for comments...
Long ago, i got tired of submitting drafts for comments to have to wait. I took spot's advice and just submitted them for review and comment simultaneously. The principle idea was that I put a deadline on the commenting period, and if there were no comments by a certain time, then it would go straight to review. This way, two groups of people got a chance to look at the drafts at the same time.
Finally, it went for a review by the Committee, and they made their comments. We also discussed your comments. I addressed their comments, which was the final request for review.
Like I said (accidentally offlist), it's not set in stone either, I'm still listening.
-Yaakov
Fedora-haskell-list mailing list Fedora-haskell-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-haskell-list
Hi,
Bryan O'Sullivan さんは書きました:
Frankly, I think that the current version of the guidelines is fine. It's much better to have something not quite perfect where we can make progress than to be permanently stuck. So moving forwards with what we have suits me.
I finally took a deep look at cabal-rpm (never actually used it before!;) and realised that that is largely the source of all my problems with the current guidelines...
Below is a patch against darcs head which backports most of my changes to the guidelines to cabal-rpm. If we're using cabal-rpm for packaging then we really don't need to add rpm macros IMHO.
Thanks for all the comments.
Jens
If we're using cabal-rpm for packaging then we really don't need to add rpm macros IMHO.
I am very much in favor of having good set of base macros (under /etc/rpm/). I have developed some simple rpms using the macros posted by Yaakov and Jens (which needed to be tweaked a bit), and was quite happy with the results. I will share those in the following email.
-Rajesh
On 2008-08-28-Thu 12:23:11 am Jens Petersen wrote:
Hi,
Bryan O'Sullivan さんは書きました:
Frankly, I think that the current version of the guidelines is fine. It's much better to have something not quite perfect where we can make progress than to be permanently stuck. So moving forwards with what we have suits me.
I finally took a deep look at cabal-rpm (never actually used it before!;) and realised that that is largely the source of all my problems with the current guidelines...
Below is a patch against darcs head which backports most of my changes to the guidelines to cabal-rpm. If we're using cabal-rpm for packaging then we really don't need to add rpm macros IMHO.
Thanks for all the comments.
Jens
On Thu, Aug 28, 2008 at 1:16 AM, Rajesh Krishnan fedora@krishnan.cc wrote:
If we're using cabal-rpm for packaging then we really don't need to add rpm macros IMHO.
I am very much in favor of having good set of base macros (under /etc/rpm/).
I like to have both the macros and cabal-rpm, where the latter assumes the presence of the former.
Bryan,
I have forked cabal-rpm (with due credits to you, and the code is still GPL) that does generation of the Fedora specific SPEC file only, with the new macros. I chose to do that because there were too many changes I needed to get some things right, and get rid of other stuff (like executing rpmbuild) that were irrelevant for my purposes.
I would publish the code once it becomes half stable and somewhat working.
Please don't take this otherwise, as your code is absolutely great Haskell work and I learned some finer Haskell coding styles while studying your code.
-Rajesh
On 2008-08-28-Thu 06:44:05 am Bryan O'Sullivan wrote:
On Thu, Aug 28, 2008 at 1:16 AM, Rajesh Krishnan fedora@krishnan.cc wrote:
If we're using cabal-rpm for packaging then we really don't need to add rpm macros IMHO.
I am very much in favor of having good set of base macros (under /etc/rpm/).
I like to have both the macros and cabal-rpm, where the latter assumes the presence of the former.
On 8/28/08, Rajesh Krishnan fedora@krishnan.cc wrote:
Bryan,
I have forked cabal-rpm (with due credits to you, and the code is still GPL) that does generation of the Fedora specific SPEC file only, with the new macros.
That's fine; it was what I intended to do anyway. Please send me patches.
I chose to do that because there were too many changes I needed to get some things right, and get rid of other stuff (like executing rpmbuild) that were irrelevant for my purposes.
I would publish the code once it becomes half stable and somewhat working.
Please don't take this otherwise, as your code is absolutely great Haskell work and I learned some finer Haskell coding styles while studying your code.
-Rajesh
On 2008-08-28-Thu 06:44:05 am Bryan O'Sullivan wrote:
On Thu, Aug 28, 2008 at 1:16 AM, Rajesh Krishnan fedora@krishnan.cc wrote:
If we're using cabal-rpm for packaging then we really don't need to add rpm macros IMHO.
I am very much in favor of having good set of base macros (under /etc/rpm/).
I like to have both the macros and cabal-rpm, where the latter assumes the presence of the former.
On Thu, Aug 28, 2008 at 3:23 AM, Jens Petersen petersen@redhat.com wrote:
Hi,
Bryan O'Sullivan さんは書きました:
Frankly, I think that the current version of the guidelines is fine. It's much better to have something not quite perfect where we can make progress than to be permanently stuck. So moving forwards with what we have suits me.
I finally took a deep look at cabal-rpm (never actually used it before!;) and realised that that is largely the source of all my problems with the current guidelines...
Below is a patch against darcs head which backports most of my changes to the guidelines to cabal-rpm. If we're using cabal-rpm for packaging then we really don't need to add rpm macros IMHO.
I want to move away from cabal-rpm actually.
The biggest pro for the macros is that we need the code to make sense to other reviewers that are not experienced with this. Any time a package needs to do something using something other than one of the macros, then we can have an expert come in an evaluate it.
Another reason for using the macros is that changes only need to be made to one place. While doing the guidelines, I had to make a number of changes to cabal-rpm, and were we not to use macros, every change to cabal-rpm would have to be backported to the packages in Fedora.
I'm going to put together some templates today.
-Yaakov
Jens Petersen さんは書きました:
Below is a patch against darcs head which backports most of my changes to the guidelines to cabal-rpm. If we're using cabal-rpm for packaging then we really don't need to add rpm macros IMHO.
Here is a slightly improved patch which also fixes rpmbuild and a few more tweaks that bring the output even closer to the current templates.
But sounds like this may conflict with Rajesh's changes... :-(
Jens
Jens Petersen さんは書きました:
Here is a slightly improved patch which also fixes rpmbuild and a few more tweaks that bring the output even closer to the current templates.
attached here
diff -rN -u old-cabal-rpm.darcs/src/Distribution/Package/Rpm.hs new-cabal-rpm.darcs/src/Distribution/Package/Rpm.hs --- old-cabal-rpm.darcs/src/Distribution/Package/Rpm.hs 2008-08-29 14:09:57.000000000 +1000 +++ new-cabal-rpm.darcs/src/Distribution/Package/Rpm.hs 2008-08-29 14:09:57.000000000 +1000 @@ -149,20 +149,18 @@ (compiler, pkgDesc) <- simplePackageDescription genPkgDesc flags let verbose = rpmVerbosity flags tmpDir = tgtPfx </> "src" - flip mapM_ ["BUILD", "RPMS", "SOURCES", "SPECS", "SRPMS"] $ \ subDir -> do - createDirectoryIfMissing True (tgtPfx </> subDir) - let specsDir = tgtPfx </> "SPECS" + createDirectoryIfMissing True (tgtPfx </> "rpm") + let rpmDir = tgtPfx </> "rpm" lbi <- localBuildInfo pkgDesc flags bracket (setFileCreationMask 0o022) setFileCreationMask $ \ _ -> do autoreconf verbose pkgDesc (specFile, extraDocs) <- createSpecFile True pkgDesc flags compiler - specsDir + rpmDir tree <- prepareTree pkgDesc verbose (Just lbi) False tmpDir knownSuffixHandlers 0 mapM_ (copyTo verbose tree) extraDocs - createArchive pkgDesc verbose (Just lbi) tmpDir (tgtPfx </> "SOURCES") - ret <- system ("rpmbuild -ba --define "_topdir " ++ tgtPfx ++ "" " ++ - specFile) + createArchive pkgDesc verbose (Just lbi) tmpDir tgtPfx + ret <- system ("rpmbuild -ba --define "_topdir " ++ rpmDir ++ "" --define "_sourcedir " ++ tgtPfx ++ "" " ++ specFile) case ret of ExitSuccess -> return () ExitFailure n -> die ("rpmbuild failed with status " ++ show n) @@ -196,25 +194,24 @@ defRelease <- defaultRelease now let pkg = package pkgDesc verbose = rpmVerbosity flags - origName = pkgName pkg - name = maybe (map toLower origName) id (rpmName flags) + name = maybe (pkgName pkg) id (rpmName flags) version = maybe ((showVersion . pkgVersion) pkg) id (rpmVersion flags) release = maybe defRelease id (rpmRelease flags) - specPath = tgtPfx </> name ++ ".spec" group = "Development/Languages" buildRoot = "%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)" cmplrVersion = compilerVersion compiler doHaddock = rpmHaddock flags && hasLibs pkgDesc flavor = compilerFlavor compiler isExec = isExecutable pkgDesc - subPackage = if isExec then "-n %{hsc_name}-%{lc_name}" else "" - (cmplr, runner) <- case flavor of - GHC -> return ("ghc", "runghc") - Hugs -> return ("hugs", "runhugs") - JHC -> return ("jhc", "runjhc") - NHC -> return ("nhc", "runnhc") - (OtherCompiler s) -> return (s, "run" ++ s) + subPackage = if isExec then " -n %{hsc_name}-%{pkg_name}" else "" + cmplr <- case flavor of + GHC -> return "ghc" + Hugs -> return "hugs" + JHC -> return "jhc" + NHC -> return "nhc" + (OtherCompiler s) -> return s _ -> die $ show flavor ++ " is not supported" + let specPath = tgtPfx </> (if isExec then name else cmplr ++ "-" ++ name) ++ ".spec" unless force $ do specAlreadyExists <- doesFileExist specPath when specAlreadyExists $ @@ -230,25 +227,22 @@ putNewline = hPutStrLn h "" put s = hPutStrLn h s putDef v s = put $ "%define " ++ v ++ ' ' : s - putSetup s = put $ runner ++ " Setup " ++ s + putSetup s = put $ "%{_cabal}" ++ " " ++ s date = formatTime defaultTimeLocale "%a %b %d %Y" now + put "# Haskell package name" + putDef "pkg_name" name + put "# Haskell compiler" putDef "hsc_name" cmplr putDef "hsc_version" $ showVersion cmplrVersion - putDef "hsc_namever" $ compilerNameVersion compiler - put "# Original Haskell package name, and lowercased form." - putDef "pkg_name" origName - putDef "lc_name" name - putDef "pkg_libdir" "%{_libdir}/%{hsc_name}-%{hsc_version}/%{pkg_name}-%{version}" - putDef "tar_dir" "%{_builddir}/%{?buildsubdir}" putNewline + putDef "pkg_libdir" "%{_libdir}/%{hsc_name}-%{hsc_version}/%{pkg_name}-%{version}" + putDef "_cabal" $ "%{_bindir}/run" ++ "%{hsc_name}" ++ " Setup" put "# Haskell compilers do not emit debug information." putDef "debug_package" "%{nil}" putNewline
- when isExec $ do - putHdr "Name" "%{lc_name}" - unless isExec $ do - putHdr "Name" "%{hsc_name}-%{lc_name}" + if isExec then putHdr "Name" "%{pkg_name}" + else putHdr "Name" "%{hsc_name}-%{pkg_name}" putHdr "Version" version putHdr "Release" $ release ++ "%{?dist}" putHdr "License" $ (showLicense . license) pkgDesc @@ -266,7 +260,7 @@ else rstrip (== '.') syn' when synTooLong $ warn verbose "The synopsis for this package spans multiple lines." - putHdrD "Summary" summary "This package has no summary" + putHdrD "Summary" summary "FIXME: This package has no summary" putHdr "BuildRoot" buildRoot putHdr "BuildRequires" buildReq -- External libraries incur both build-time and runtime @@ -279,16 +273,14 @@ unless isExec $ do putHdr_ "Requires" extraReq putHdr_ "Requires" runtimeReq - putHdr "Provides" "%{pkg_name}-%{hsc_namever} = %{version}"
putNewline - putNewline
let putDesc = do put $ if (null . description) pkgDesc then if synTooLong then syn - else "This package does not have a description." + else "FIXME: This package does not have a description." else description pkgDesc put "%description" putDesc @@ -303,17 +295,15 @@ management system. -}
when isExec $ withLib pkgDesc () $ _ -> do - put "%package -n %{hsc_name}-%{lc_name}" - putHdrD "Summary" summary "This library package has no summary" + put "%package -n %{hsc_name}-%{pkg_name}" + putHdrD "Summary" summary "FIXME: This library package has no summary" putHdr "Group" "Development/Libraries" putHdr "Requires" "%{hsc_name} = %{hsc_version}" putHdr_ "Requires" extraReq putHdr_ "Requires" runtimeReq - putHdr "Provides" "%{pkg_name}-%{hsc_namever} = %{version}" - putNewline putNewline
- put "%description -n %{hsc_name}-%{lc_name}" + put "%description -n %{hsc_name}-%{pkg_name}" putDesc putNewline put "This package contains libraries for %{hsc_name} %{hsc_version}." @@ -321,15 +311,13 @@ putNewline
when (rpmLibProf flags) $ do - put "%package -n %{hsc_name}-%{lc_name}-prof" - putHdr "Summary" "Profiling libraries for %{hsc_name}-%{lc_name}" + put "%package -n %{hsc_name}-%{pkg_name}-prof" + putHdr "Summary" "Profiling libraries for %{hsc_name}-%{pkg_name}" putHdr "Group" "Development/Libraries" - putHdr "Requires" "%{hsc_name}-%{lc_name} = %{version}" - putHdr "Provides" "%{pkg_name}-%{hsc_namever}-prof = %{version}" - putNewline + putHdr "Requires" "%{hsc_name}-%{pkg_name} = %{version}-%{release}" putNewline
- put "%description -n %{hsc_name}-%{lc_name}-prof" + put "%description -n %{hsc_name}-%{pkg_name}-prof" putDesc putNewline put "This package contains profiling libraries for %{hsc_name} %{hsc_version}." @@ -344,14 +332,14 @@ put "%build" put "if [ -f configure.ac -a ! -f configure ]; then autoreconf; fi" putSetup ("configure --prefix=%{_prefix} --libdir=%{_libdir} " ++ - "--docdir=%{_docdir}/%{hsc_name}-%{lc_name}-%{version} " ++ + "--docdir=%{_docdir}/%{hsc_name}-%{pkg_name}-%{version} " ++ "--libsubdir='$compiler/$pkgid' " ++ (let cfg = rpmConfigurationsFlags flags in if null cfg then "" else "--flags='" ++ joinConfigurations cfg ++ "' ") ++ (if (rpmLibProf flags) then "--enable" else "--disable") ++ - "-library-profiling --" ++ cmplr) + "-library-profiling --" ++ "%{hsc_name}") withLib pkgDesc () $ _ -> do hPutStr h "if " putSetup "makefile -f cabal-rpm.mk" @@ -374,15 +362,16 @@ putSetup "copy --destdir=${RPM_BUILD_ROOT}" withLib pkgDesc () $ _ -> do put "install -m 755 register.sh unregister.sh ${RPM_BUILD_ROOT}%{pkg_libdir}" - put "cd ${RPM_BUILD_ROOT}" - put "echo '%defattr (-,root,root,-)' > %{tar_dir}/%{name}-files.prof" - put "find .%{pkg_libdir} \( -name '*_p.a' -o -name '*.p_hi' \) | sed s/^.// >> %{tar_dir}/%{name}-files.prof" - put "echo '%defattr (-,root,root,-)' > %{tar_dir}/%{name}-files.nonprof" - put "find .%{pkg_libdir} -type d | sed 's/^./%dir /' >> %{tar_dir}/%{name}-files.nonprof" - put "find .%{pkg_libdir} ! \( -type d -o -name '*_p.a' -o -name '*.p_hi' \) | sed s/^.// >> %{tar_dir}/%{name}-files.nonprof" - put "sed 's,^/,%exclude /,' %{tar_dir}/%{name}-files.prof >> %{tar_dir}/%{name}-files.nonprof" + putNewline + put "rm -f %{name}.files %{name}-prof.files" + put "echo '%defattr(-,root,root,-)' > %{name}-prof.files" + put "find ${RPM_BUILD_ROOT}%{pkg_libdir} \( -name '*_p.a' -o -name '*.p_hi' \) >> %{name}-prof.files" + put "echo '%defattr(-,root,root,-)' > %{name}.files" + put "find ${RPM_BUILD_ROOT}%{pkg_libdir} -type d | sed 's/^/%dir /' >> %{name}.files" + put "find ${RPM_BUILD_ROOT}%{pkg_libdir} ! \( -type d -o -name '*_p.a' -o -name '*.p_hi' \) >> %{name}.files" + put $ "sed -i -e "s!${RPM_BUILD_ROOT}!!g"" ++ " " ++ "%{name}.files %{name}-prof.files" putNewline - put "cd ${RPM_BUILD_ROOT}/%{_datadir}/doc/%{hsc_name}-%{lc_name}-%{version}" + put "cd ${RPM_BUILD_ROOT}/%{_datadir}/doc/%{hsc_name}-%{pkg_name}-%{version}" put $ "rm -rf doc " ++ concat (intersperse " " docs) putNewline putNewline @@ -405,12 +394,12 @@ same location as the about-to-be-installed library's script. -}
- put $ "%pre " ++ subPackage + put $ "%pre" ++ subPackage put "[ "$1" = 2 ] && %{pkg_libdir}/unregister.sh >&/dev/null || :" putNewline putNewline
- put $ "%post " ++ subPackage + put $ "%post" ++ subPackage put "%{pkg_libdir}/register.sh >&/dev/null" putNewline putNewline @@ -420,7 +409,7 @@ runtime's package system will be left with a phantom record for a package it can no longer use. -}
- put $ "%preun " ++ subPackage + put $ "%preun" ++ subPackage put "%{pkg_libdir}/unregister.sh >&/dev/null" putNewline putNewline @@ -430,12 +419,12 @@ Cabal name+version, even though the RPM release differs); therefore, we must attempt to re-register it. -}
- put $ "%postun " ++ subPackage + put $ "%postun" ++ subPackage put "[ "$1" = 1 ] && %{pkg_libdir}/register.sh >& /dev/null || :" putNewline putNewline
- put $ "%files " ++ subPackage ++ " -f %{name}-files.nonprof" + put $ "%files" ++ subPackage ++ " -f %{name}.files" when doHaddock $ put "%doc dist/doc/html" when ((not . null) docs) $ @@ -444,7 +433,7 @@ putNewline
when (rpmLibProf flags) $ do - put "%files -n %{hsc_name}-%{lc_name}-prof -f %{name}-files.prof" + put "%files -n %{hsc_name}-%{pkg_name}-prof -f %{name}-prof.files" put $ "%doc " ++ licenseFile pkgDesc putNewline putNewline @@ -454,7 +443,7 @@ put "%defattr (-,root,root,-)" withExe pkgDesc $ \exe -> put $ "%{_bindir}/" ++ exeName exe when (((not . null . dataFiles) pkgDesc) && isExec) $ - put "%{_datadir}/%{lc_name}-%{version}" + put "%{_datadir}/%{pkg_name}-%{version}"
-- Add the license file to the main package only if it wouldn't -- otherwise be empty. @@ -537,18 +526,12 @@ -> IO String
showBuildReq verbose haddock c pkgDesc = do - cPkg <- case compilerFlavor c of - GHC -> return "ghc" - Hugs -> return "hugs98" - _ -> die $ "cannot deal with compiler " ++ show c - let cVersion = pkgVersion $ compilerId c - myDeps = [Dependency cPkg (ThisVersion cVersion)] ++ - if haddock then [Dependency "haddock" AnyVersion] else [] + let myDeps = if haddock then [Dependency "haddock" AnyVersion] else [] externalDeps = filter (not . isBundled c) (buildDepends pkgDesc) exReqs <- mapM (showRpmReq verbose (virtualPackage c)) externalDeps myReqs <- mapM (showRpmReq verbose id) myDeps - return $ (commaSep . concat) (myReqs ++ exReqs) + return $ "%{hsc_name} = %{hsc_version}, " ++ (commaSep . concat) (myReqs ++ exReqs)
-- | Represent a dependency in a form suitable for an RPM spec file.
Yaakov / Jens,
Have we finally decided if what style of macros we wish to move forward with (ghc_* v/s cabal_*)? I looked at Jens' update for the macros file and liked the syntax, and created this sample package for the latest version of Cabal (1.4.0.2). The specified SPEC below compiles well on F8 and F9 (the rpmbuild command on rawhide (F10) seems to have BuildRoot resolution issues at the moment, and may not build on rawhide). Here are the F9 source and binaries (tested on F9 on amd64, with ghc-6.8.3):
RPM(x86_64): http://krishnan.cc/devel/repository/fedora/RPMS/x86_64/ghc-cabal-1.4.0.2-1.f...
RPM(i386): http://krishnan.cc/devel/repository/fedora/RPMS/i386/ghc-cabal-1.4.0.2-1.fc9...
SPEC: http://krishnan.cc/devel/repository/fedora/SPECS/ghc-cabal.spec
SRPM: http://krishnan.cc/devel/repository/fedora/SRPMS/ghc-cabal-1.4.0.2-1.fc9.src...
macros.haskell: http://krishnan.cc/devel/repository/fedora/MISC/macros.haskell (This is the modified file with cabal_* style macros as proposed by Jens. Note that we need to place macros.haskell under /etc/rpm to successfully build with the above .spec).
YAAKOV: Note that the macros.haskell file needs another variable called %{internal_name} which needs to get defined in the spec for Hackage that start with a capital letter (like the Cabal example mentioned here). Otherwise it IMHO it is not possible keep the resulting rpm name (ghc-cabal) in all lowercase letters as per the Haskell package building specification.
If we have decided stay with the original macros.ghc style macros (ghc_*) then I can update the package and resubmit with the modified macros.ghc file. I am not biased towards either macros.ghc or macros.haskell, and either one of them is fine with me (will need to tweak them a bit of course).
And also, could somebody help me with getting some file-hosting space on FedoraPeople or Fedoraproject sites? That would help me upload the packages and spec related files for public sharing.
Let me know if anyone is unable to access the files over the URLs mentioned above.
-Rajesh
-
On 2008-08-27-Wed 06:00:01 pm Yaakov Nemoy wrote:
On Wed, Aug 27, 2008 at 8:26 PM, Jens Petersen petersen@redhat.com wrote:
Hi Jason,
Because the draft was submitted to us as complete, and we voted on it.
I understood that it was submitted as a draft for comments...
Long ago, i got tired of submitting drafts for comments to have to wait. I took spot's advice and just submitted them for review and comment simultaneously. The principle idea was that I put a deadline on the commenting period, and if there were no comments by a certain time, then it would go straight to review. This way, two groups of people got a chance to look at the drafts at the same time.
Finally, it went for a review by the Committee, and they made their comments. We also discussed your comments. I addressed their comments, which was the final request for review.
Like I said (accidentally offlist), it's not set in stone either, I'm still listening.
-Yaakov
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
On Thu, Aug 28, 2008 at 10:50 AM, Rajesh Krishnan fedora@krishnan.cc wrote:
Have we finally decided if what style of macros we wish to move forward with (ghc_* v/s cabal_*)? I looked at Jens' update for the macros file and liked the syntax, and created this sample package for the latest version of Cabal (1.4.0.2).
From the spec file:
%changelog * Wed Aug 27 2008 cabal-rpm cabal-devel@haskell.org - 1.4.0.2-1 - spec file autogenerated by cabal-rpm
Is that true? If so, were any manual tweaks to the output for cabal-rpm necessary?
Cheers,
Miles
Miles,
Please don't read too much into the changelog for now. It is just a generated stub. The code that generated that spec is not cabal-rpm (but a fork with my custom modifications). -Rajesh
On 2008-08-28-Thu 04:17:43 am Miles Sabin wrote:
On Thu, Aug 28, 2008 at 10:50 AM, Rajesh Krishnan fedora@krishnan.cc
wrote:
Have we finally decided if what style of macros we wish to move forward with (ghc_* v/s cabal_*)? I looked at Jens' update for the macros file and liked the syntax, and created this sample package for the latest version of Cabal (1.4.0.2).
From the spec file:
%changelog
- Wed Aug 27 2008 cabal-rpm cabal-devel@haskell.org - 1.4.0.2-1
- spec file autogenerated by cabal-rpm
Is that true? If so, were any manual tweaks to the output for cabal-rpm necessary?
Cheers,
Miles
Fedora-haskell-list mailing list Fedora-haskell-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-haskell-list
On Thu, Aug 28, 2008 at 5:50 AM, Rajesh Krishnan fedora@krishnan.cc wrote:
Yaakov / Jens,
Have we finally decided if what style of macros we wish to move forward with (ghc_* v/s cabal_*)? I looked at Jens' update for the macros file and liked the syntax, and created this sample package for the latest version of Cabal (1.4.0.2). The specified SPEC below compiles well on F8 and F9 (the rpmbuild command on rawhide (F10) seems to have BuildRoot resolution issues at the moment, and may not build on rawhide). Here are the F9 source and binaries (tested on F9 on amd64, with ghc-6.8.3):
cabal_* is a no go. It makes it *much* harder to support multiple compilers in the future. Remember these rules.
All libraries theoretically need to have a seperate spec file (thus seperate package in CVS) for each compiler we ship. Thus: ghc-foo hugs98-foo barhc-foo
For library foo in hackage.
All packages that also ship with executables should be compiled with GHC (or give a good justification for using another compiler), thus: xmonad darcs haddock
For xmonad, darcs, and haddock.
Packages that do code generation, and ship both libraries and executables should also use GHC, but the library component should be named after GHC. Note that the library component is just a subpackage of the executable. Thus: xmonad
For xmonad.
RPM(x86_64): http://krishnan.cc/devel/repository/fedora/RPMS/x86_64/ghc-cabal-1.4.0.2-1.f...
RPM(i386): http://krishnan.cc/devel/repository/fedora/RPMS/i386/ghc-cabal-1.4.0.2-1.fc9...
SPEC: http://krishnan.cc/devel/repository/fedora/SPECS/ghc-cabal.spec
SRPM: http://krishnan.cc/devel/repository/fedora/SRPMS/ghc-cabal-1.4.0.2-1.fc9.src...
macros.haskell: http://krishnan.cc/devel/repository/fedora/MISC/macros.haskell (This is the modified file with cabal_* style macros as proposed by Jens. Note that we need to place macros.haskell under /etc/rpm to successfully build with the above .spec).
YAAKOV: Note that the macros.haskell file needs another variable called %{internal_name} which needs to get defined in the spec for Hackage that start with a capital letter (like the Cabal example mentioned here). Otherwise it IMHO it is not possible keep the resulting rpm name (ghc-cabal) in all lowercase letters as per the Haskell package building specification.
Uh, that part changed. We are now going with upstream names. This was to reduce complexity, since Upstream uses a consistent naming scheme.
If we have decided stay with the original macros.ghc style macros (ghc_*) then I can update the package and resubmit with the modified macros.ghc file. I am not biased towards either macros.ghc or macros.haskell, and either one of them is fine with me (will need to tweak them a bit of course).
And also, could somebody help me with getting some file-hosting space on FedoraPeople or Fedoraproject sites? That would help me upload the packages and spec related files for public sharing.
You should have some already with your FAS account.
-Yaakov
Yaakov,
For Hackage packages that contain only libraries, or a single executable, the package building specification is clear (name the RPM for library only package xyz as ghc-xyz, and name the RPM for a single executable package xyz as just xyz without the ghc prefix).
But the part of the specification is not clear to me is:
What would be the RPM name for a Hackage package xyz that contains multiple libraries and multiple executables? Is it OK to create a single RPM called xyz in for such a package, or do they necessarily need to be split up into multiple package fragments? Please explain if you could. Note that the number of such fragmented RPMs would multiply fast (creation of perhaps -prof and -doc etc. if applicable for each subpackage) .
Thanks in advance. -Rajesh
On 2008-08-28-Thu 11:28:08 am Yaakov Nemoy wrote:
On Thu, Aug 28, 2008 at 5:50 AM, Rajesh Krishnan fedora@krishnan.cc wrote:
Yaakov / Jens,
Have we finally decided if what style of macros we wish to move forward with (ghc_* v/s cabal_*)? I looked at Jens' update for the macros file and liked the syntax, and created this sample package for the latest version of Cabal (1.4.0.2). The specified SPEC below compiles well on F8 and F9 (the rpmbuild command on rawhide (F10) seems to have BuildRoot resolution issues at the moment, and may not build on rawhide). Here are the F9 source and binaries (tested on F9 on amd64, with ghc-6.8.3):
cabal_* is a no go. It makes it *much* harder to support multiple compilers in the future. Remember these rules.
All libraries theoretically need to have a seperate spec file (thus seperate package in CVS) for each compiler we ship. Thus: ghc-foo hugs98-foo barhc-foo
For library foo in hackage.
All packages that also ship with executables should be compiled with GHC (or give a good justification for using another compiler), thus: xmonad darcs haddock
For xmonad, darcs, and haddock.
Packages that do code generation, and ship both libraries and executables should also use GHC, but the library component should be named after GHC. Note that the library component is just a subpackage of the executable. Thus: xmonad
For xmonad.
RPM(x86_64): http://krishnan.cc/devel/repository/fedora/RPMS/x86_64/ghc-cabal-1.4.0.2- 1.fc9.x86_64.rpm
RPM(i386): http://krishnan.cc/devel/repository/fedora/RPMS/i386/ghc-cabal-1.4.0.2-1. fc9.i386.rpm
SPEC: http://krishnan.cc/devel/repository/fedora/SPECS/ghc-cabal.spec
SRPM: http://krishnan.cc/devel/repository/fedora/SRPMS/ghc-cabal-1.4.0.2-1.fc9. src.rpm
macros.haskell: http://krishnan.cc/devel/repository/fedora/MISC/macros.haskell (This is the modified file with cabal_* style macros as proposed by Jens. Note that we need to place macros.haskell under /etc/rpm to successfully build with the above .spec).
YAAKOV: Note that the macros.haskell file needs another variable called %{internal_name} which needs to get defined in the spec for Hackage that start with a capital letter (like the Cabal example mentioned here). Otherwise it IMHO it is not possible keep the resulting rpm name (ghc-cabal) in all lowercase letters as per the Haskell package building specification.
Uh, that part changed. We are now going with upstream names. This was to reduce complexity, since Upstream uses a consistent naming scheme.
If we have decided stay with the original macros.ghc style macros (ghc_*) then I can update the package and resubmit with the modified macros.ghc file. I am not biased towards either macros.ghc or macros.haskell, and either one of them is fine with me (will need to tweak them a bit of course).
And also, could somebody help me with getting some file-hosting space on FedoraPeople or Fedoraproject sites? That would help me upload the packages and spec related files for public sharing.
You should have some already with your FAS account.
-Yaakov
On Thu, Aug 28, 2008 at 6:20 PM, Rajesh Krishnan fedora@krishnan.cc wrote:
Yaakov,
For Hackage packages that contain only libraries, or a single executable, the package building specification is clear (name the RPM for library only package xyz as ghc-xyz, and name the RPM for a single executable package xyz as just xyz without the ghc prefix).
But the part of the specification is not clear to me is:
What would be the RPM name for a Hackage package xyz that contains multiple libraries and multiple executables? Is it OK to create a single RPM called xyz in for such a package, or do they necessarily need to be split up into multiple package fragments? Please explain if you could. Note that the number of such fragmented RPMs would multiply fast (creation of perhaps -prof and -doc etc. if applicable for each subpackage) .
Thanks in advance. -Rajesh
Can you give me an example?
It's not unreasonable for a package to install multiple executables either, mind you that they are all connected in some way. It's a bit stranger that there are multiple libraries involved, all coming from a single source tarball. Perhaps upstream needs to split up what it's doing into several source packages?
-Yaakov
Rajesh Krishnan さんは書きました:
For Hackage packages that contain only libraries, or a single executable, the package building specification is clear (name the RPM for library only package xyz as ghc-xyz, and name the RPM for a single executable package xyz as just xyz without the ghc prefix).
The example corresponding to xmonad (which has both an executable and library) is given in the guidelines: the base package name in that case should be just "xmonad".
What would be the RPM name for a Hackage package xyz that contains multiple libraries and multiple executables? Is it OK to create a single RPM called xyz in for such a package, or do they necessarily need to be split up into multiple package fragments? Please explain if you could. Note that the number of such fragmented RPMs would multiply fast (creation of perhaps -prof and -doc etc. if applicable for each subpackage) .
So do you have a specific package in mind? It is easier to discuss concrete examples than hypothetical cases. :)
Jens
So do you have a specific package in mind?
Well I don't have any specific example available just over the top of my head. But from what I know about Cabal file format , it should be quite trivial to create a package that has 1 library and more than 1 executable sections. Though I haven't come across any .cabal file with more than 1 library sections (and a single library section is almost always sufficient), the Cabal documentation does not state clearly if more than 1 library sections could be present or not (I just checked, though I haven't experimentally verified this).
-Rajesh
On 2008-08-28-Thu 05:03:36 pm Jens Petersen wrote:
Rajesh Krishnan さんは書きました:
For Hackage packages that contain only libraries, or a single executable, the package building specification is clear (name the RPM for library only package xyz as ghc-xyz, and name the RPM for a single executable package xyz as just xyz without the ghc prefix).
The example corresponding to xmonad (which has both an executable and library) is given in the guidelines: the base package name in that case should be just "xmonad".
What would be the RPM name for a Hackage package xyz that contains multiple libraries and multiple executables? Is it OK to create a single RPM called xyz in for such a package, or do they necessarily need to be split up into multiple package fragments? Please explain if you could. Note that the number of such fragmented RPMs would multiply fast (creation of perhaps -prof and -doc etc. if applicable for each subpackage) .
So do you have a specific package in mind? It is easier to discuss concrete examples than hypothetical cases. :)
Jens
Yaakov Nemoy さんは書きました:
cabal_* is a no go. It makes it *much* harder to support multiple compilers in the future. Remember these rules.
I am not sure. If Cabal is compiler/interpreter agnostic as it is supposed to be I thought, we can just use runhaskell to run it without having to worry about what runtime we are building for? Or is that oversimplying? Of course, sure, we still need build options for different compilers but the running of the build process should not depend heavily on it?
Maybe Bryan can clarify this point?
Jens
On Thu, Aug 28, 2008 at 7:49 PM, Jens Petersen petersen@redhat.com wrote:
Yaakov Nemoy さんは書きました:
cabal_* is a no go. It makes it *much* harder to support multiple compilers in the future. Remember these rules.
I am not sure. If Cabal is compiler/interpreter agnostic as it is supposed to be I thought, we can just use runhaskell to run it without having to worry about what runtime we are building for? Or is that oversimplying? Of course, sure, we still need build options for different compilers but the running of the build process should not depend heavily on it?
Maybe Bryan can clarify this point?
Jens
If we do this, then each 'library' package is going to have to support every single compiler we have. I would rather have one SRPM per library per compiler. Calling runhaskell will only call the default compiler, which in Fedora's case is GHC.
-Yaakov
Yaakov Nemoy さんは書きました:
If we do this, then each 'library' package is going to have to support every single compiler we have.
No they don't have to but they can if they want. :)
I would rather have one SRPM per library per compiler.
I thought we proposed "haskell-%pkg_name" exactly for this?
Calling runhaskell will only call the default compiler, which in Fedora's case is GHC.
Well it depends what you have installed (it is handled by alternatives). But as I say it should not matter what runtime is used to run Setup.hs?
Jens
2008/8/28 Jens Petersen petersen@redhat.com:
Yaakov Nemoy さんは書きました:
If we do this, then each 'library' package is going to have to support every single compiler we have.
No they don't have to but they can if they want. :)
It would be messy.
I would rather have one SRPM per library per compiler.
I thought we proposed "haskell-%pkg_name" exactly for this?
Nope, that's why it's %haskell_compiler-%pkg_name exactly for this. Otherwise, we can only support one compiler without a lot of weird tricks.
(Granted, we could just include multiple macros for multiple compilers in a single spec file, and then build and publish a single RPM for each library that supports multiple compilers. I think this would lead to alot of bloat. Alternatively, we could have a single spec file per library, and have it generate multiple subpackages, one for each compiler. I would rather have one spec per compiler per library.)
Calling runhaskell will only call the default compiler, which in Fedora's case is GHC.
Well it depends what you have installed (it is handled by alternatives). But as I say it should not matter what runtime is used to run Setup.hs?
AFAIK, the run time you use to run Setup.hs is the runtime that the library is compiled against. Namely, runhaskell that runs runghc would create a package for GHC.
-Yaakov
Yaakov Nemoy さんは書きました:
2008/8/28 Jens Petersen petersen@redhat.com:
Yaakov Nemoy さんは書きました:
If we do this, then each 'library' package is going to have to support every single compiler we have.
No they don't have to but they can if they want. :)
It would be messy.
I would rather have one SRPM per library per compiler.
I thought we proposed "haskell-%pkg_name" exactly for this?
Nope, that's why it's %haskell_compiler-%pkg_name exactly for this. Otherwise, we can only support one compiler without a lot of weird tricks.
I quote from PackagingDrafts/Haskell...:
"If a library supports multiple Haskell compilers or interpreters, the base name should instead be prefixed with haskell, e.g. haskell-X11."
So you want to withtract this? :)
(Granted, we could just include multiple macros for multiple compilers in a single spec file, and then build and publish a single RPM for each library that supports multiple compilers. I think this would lead to alot of bloat. Alternatively, we could have a single spec file per library, and have it generate multiple subpackages, one for each compiler. I would rather have one spec per compiler per library.)
Well that is what they do in the Emacs Lisp world for Emacs and XEmacs and it works: it is a really pain having to maintain parallel packages for different compiler.
Actually we could face this problem immediately if Rajesh submits haskell-Cabal, since it should really be packaged for both ghc and hugs98.
AFAIK, the run time you use to run Setup.hs is the runtime that the library is compiled against. Namely, runhaskell that runs runghc would create a package for GHC.
I don't think it matters since it is only "scripting" and cabal is supposed to be portable Haskell98 presumably.
Jens
Actually we could face this problem immediately if Rajesh submits haskell-Cabal, since it should really be packaged for both ghc and hugs98.
The package I submitted earlier in this thread IS haskell-cabal. It is named ghc-cabal simply because I used ghc to compile it. Look at the macros.haskell that it depends on, and you will see what I mean.
I can see Yaakov's point too, of having the macro file as macros.ghc which is specific to ghc.
Actually we could face this problem immediately if Rajesh submits haskell-Cabal, since it should really be packaged for both ghc and hugs98.
Wait a minute, Jens! You are asking for too much! At this time, I am not too much interested in getting into hugs98, and I don't plan test any packages I submit on Hugs or other Haskell platforms for now.
But maybe in future others who join the team might want to create a specific set of packages for Hugs98. They would then have the freedom to create their specific macro file called macros.hugs and create and submit their favorite packages like hugs-<package>.rpm or something.
-Rajesh
On 2008-08-28-Thu 07:42:13 pm Jens Petersen wrote:
Yaakov Nemoy さんは書きました:
2008/8/28 Jens Petersen petersen@redhat.com:
Yaakov Nemoy さんは書きました:
If we do this, then each 'library' package is going to have to support every single compiler we have.
No they don't have to but they can if they want. :)
It would be messy.
I would rather have one SRPM per library per compiler.
I thought we proposed "haskell-%pkg_name" exactly for this?
Nope, that's why it's %haskell_compiler-%pkg_name exactly for this. Otherwise, we can only support one compiler without a lot of weird tricks.
I quote from PackagingDrafts/Haskell...:
"If a library supports multiple Haskell compilers or interpreters, the base name should instead be prefixed with haskell, e.g. haskell-X11."
So you want to withtract this? :)
(Granted, we could just include multiple macros for multiple compilers in a single spec file, and then build and publish a single RPM for each library that supports multiple compilers. I think this would lead to alot of bloat. Alternatively, we could have a single spec file per library, and have it generate multiple subpackages, one for each compiler. I would rather have one spec per compiler per library.)
Well that is what they do in the Emacs Lisp world for Emacs and XEmacs and it works: it is a really pain having to maintain parallel packages for different compiler.
Actually we could face this problem immediately if Rajesh submits haskell-Cabal, since it should really be packaged for both ghc and hugs98.
AFAIK, the run time you use to run Setup.hs is the runtime that the library is compiled against. Namely, runhaskell that runs runghc would create a package for GHC.
I don't think it matters since it is only "scripting" and cabal is supposed to be portable Haskell98 presumably.
Jens
Yaakov,
I have built ghc-cabal with a modified version of your macros.ghc file (link below). Here are the resulting packages. The following were tested with F8 and F9 (Did not test against Rawhide(F10) as I think rpmbuild on F10 has some issues related to buildroot resolution).
RPM(x86_64 and -prof): http://krishnan.cc/devel/repository/fedora/RPMS/x86_64/ghc-cabal-1.4.0.2-2.f... http://krishnan.cc/devel/repository/fedora/RPMS/x86_64/ghc-cabal-prof-1.4.0....
RPM(i386 and -prof): http://krishnan.cc/devel/repository/fedora/RPMS/i386/ghc-cabal-1.4.0.2-2.fc9... http://krishnan.cc/devel/repository/fedora/RPMS/i386/ghc-cabal-prof-1.4.0.2-...
SPEC: http://krishnan.cc/devel/repository/fedora/SPECS/ghc-cabal.spec
SRPM: http://krishnan.cc/devel/repository/fedora/SRPMS/ghc-cabal-1.4.0.2-2.fc9.src...
macros.ghc: http://krishnan.cc/devel/repository/fedora/MISC/macros.ghc (This is the modified file with ghc_* style macros. Note that we need to place macros.ghc under /etc/rpm/ to successfully build with the above .spec).
Let me know if you or anyone else has modified macros.ghc recently. It is a small file, so a quickly viewing this in Kompare along with the original should be easy enough to investigate the differences. Note that I foresee some more changes that might need to be introduced into macros.ghc as we gain more expertise in building other cabal packages.
BTW, going forward, how would you like me to submit packages for review request? Using the Bugzilla, or any other means? I plan to maintain a link for all the packages I submit on my wiki page, for easy reference (its not there yet).
-Rajesh
On 2008-08-28-Thu 02:50:46 am Rajesh Krishnan wrote:
RPM(x86_64): http://krishnan.cc/devel/repository/fedora/RPMS/x86_64/ghc-cabal-1.4.0.2-1. fc9.x86_64.rpm
RPM(i386): http://krishnan.cc/devel/repository/fedora/RPMS/i386/ghc-cabal-1.4.0.2-1.fc 9.i386.rpm
SPEC: http://krishnan.cc/devel/repository/fedora/SPECS/ghc-cabal.spec
SRPM: http://krishnan.cc/devel/repository/fedora/SRPMS/ghc-cabal-1.4.0.2-1.fc9.sr c.rpm
macros.haskell: http://krishnan.cc/devel/repository/fedora/MISC/macros.haskell (This is the modified file with cabal_* style macros as proposed by Jens. Note that we need to place macros.haskell under /etc/rpm to successfully build with the above .spec).
haskell-devel@lists.fedoraproject.org
-
Bryan O'Sullivan -
Jens-Ulrik Petersen -
Miles Sabin -
Rajesh Krishnan -
Yaakov Nemoy