[Bug 189197] Review Request: ghc-gtk2hs
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ghc-gtk2hs https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189197 --- Additional Comments From [EMAIL PROTECTED] 2006-05-06 19:05 EST --- (In reply to comment #9) My only concern now with the current package naming (ghc-gtk2hs) is: what happens if/when one day we want to build/package gtk2hs with another Haskell compiler or interpreter (say nhc98, jhc or hugs)? In that sense using a more generic name for the source package (eg just gtk2hs) might be better after all? (We can still have a ghc-gtk2hs subpackage of course even in this case.) Yes, that would make sense for the source package. I suppose it is not required to have an main RPM matching the name of the SRPM. I thought, maybe better not split the packages into separate packages for gconf, etc... The largest package is gtk anyway. We would have: ghc-gtk2hs ghc642-gtk2hs nhc98-gtk2hs nhc98-118-gtk2hs etc... This would be much simpler. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 189197] Review Request: ghc-gtk2hs
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ghc-gtk2hs https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189197 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #128411|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 189197] Review Request: ghc-gtk2hs
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ghc-gtk2hs https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189197 --- Additional Comments From [EMAIL PROTECTED] 2006-05-01 16:57 EST --- (In reply to comment #6) Well that works, but then the problem is that ghc642-gconf will conflict with ghc641-gconf, etc. An alternative might be to make ghc-gtk2hs pull in all the subpackages perhaps? Wouldn't that defeat the purpose of splitting off these packages? I wonder if this versioning scheme is really worth the effort. After all there are no shared libraries, where compatibility packages would be necessary. Of course everytime ghc gets updated, the dependent packages must be rebuilt... But ghc642-gtk requires ghc642, so what happens when one upgrades to ghc643? I don't think it will be possible to rebuild all ghc built libs immediately after a new ghc release typically. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 189197] Review Request: ghc-gtk2hs
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ghc-gtk2hs https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189197 --- Additional Comments From [EMAIL PROTECTED] 2006-05-01 17:26 EST --- (In reply to comment #7) But ghc642-gtk requires ghc642, so what happens when one upgrades to ghc643? I don't think it will be possible to rebuild all ghc built libs immediately after a new ghc release typically. I see the problem... There is probably no better way out in the current state of affairs. However I just wanted to have written down for the posterity that I do consider it unsatisfactory :-) The package builds fine in mock. Installing the packages works and the demo programs build perfectly well. I find it a little annoying that the doc directories are: ghc642-gtk-0.9.10 ghc-gtk2hs-doc-0.9.10 More consistent would be: ghc-gtk2hs-0.9.10 ghc-gtk2hs-doc-0.9.10 This would mean, that the doc files would go in the ghc-gtk2hs-0.9.10 package which is currently. Is is possible however to install the subpackages without the main package. Probably one could make the package ghc642-gtk require ghc-gtk2hs, so that ghc-gtk2hs is always installed. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 189197] Review Request: ghc-gtk2hs
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: Review Request: ghc-gtk2hs
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189197
--- Additional Comments From [EMAIL PROTECTED] 2006-04-27 07:29 EST ---
(In reply to comment #1)
* Could you update the package to ghc-6.4.2?
Yep, I updated the package with some changes:
http://people.redhat.com/petersen/extras/ghc-gtk2hs.spec
http://people.redhat.com/petersen/extras/ghc-gtk2hs-0.9.10-2.src.rpm
* BuildRoot must be:
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Fixed.
* Is the epoch necessary for mozilla version?
Yes.
* I think PreReq should simply be Requires
I prefer PreReq for post/preun requirements: it is equivalent to Requires
actually, but if you object I can change it.
* ghclibdir should probably %{_libdir}/ghc-%{ghc_version}
Well ghc upstream has said that %{_libdir}/ghc-%{ghc_version}
should be reserved for ghc itself. For cabalised packages
I'm using %{_libdir}/ghc as the library prefix: it would be good
if gtk2hs followed this scheme too IMHO. I hear upstream is planning
to make the install configuration more flexible, but for now maybe
the current location is good enough.
* Can you explain your system of versioning?
You mean the package naming scheme? That is a bit of a long story. :)
This is the naming scheme I have been using for a while for libraries
and ghc in Fedora Haskell http://haskell.org/fedora/. Let me try to
summarize here.
The starting point is the fact that ghc changes ABI with every minor
version update (this is the main reason for the ghcXYZ subpackaging of
ghc: ie currently there is ghc, ghc642, ghc642-prof); so since ghc is
rather a large package to rebuild as a compat- package say it
seemed to make more sense to me to allow parallel installs of ghcXYZ's (so
you can install ghc641 with ghc642, etc and still be able to compile with your
old libraries built for ghc641 say) until you can update them to ghc642.
While gtk2hs builds quicker than ghc it is still pretty
time-consuming to build, so following the ghc scheme it is subpackaged
for ghcXYZ. I decided to make subpackages for each ghc package (gtk, glib,
sourceview, etc) since they depend on the corresponding
{gtk2,glib2,sourceview}-devel packages and so people can just install what they
need: probably ghcXYZ-gtk would be most common. Again this allows parallel
installs of libraries (gtk2hs) for parallel installs of ghc.
Does that make some sense? I can go into more details if you wish.
In the latest naming scheme now I'm just using the
ghc-package name to name the subpackages (ghcXYZ-glib rather than
ghc642-gtk2hs-glib etc) since that is what the ghc package is actually called
so it seems more natural. The ghcXYZ scheme also means that if you have say
ghc641-gtk installed with ghc-6.4.1, you can upgrade to ghc-6.4.2 without
breaking the deps for ghc641 libs like gtk2hs, and then later update to
ghc642-gtk when it is available.
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the QA contact for the bug, or are watching the QA contact.
___
Fedora-package-review mailing list
Fedora-package-review@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-package-review
