Ebuild on its way.
Created attachment 253011 [details] ebuild for dev-haskell/configfile-1.0.6
Created attachment 253207 [details] Updated ebuild for dev-haskell/configfile-1.0.6 Binki spotted the incorrect <=mtl-2 on review.
Committed here, with one additional fix (reorder RDEPEND) over the attached ebuild: http://overlays.gentoo.org/proj/sunrise/browser/reviewed/dev-haskell/configfile
I don't see mtl-2 in sunrise (and it's dev-haskell/ is very tiny). parsec dep is missing. Michael, are you aware of gentoo-haskell overlay? http://code.haskell.org/gentoo/gentoo-haskell/ I'll pick latest ebuild from our overlay (it's autogenerated) to the portage tree if you don't mind.
I didn't think to look there, but I guess I implicitly knew about it =) I would rather see these things go into the main tree because I maintain >20 machines and already need to keep up with the hardened overlay, x11 overlay, my personal overlay, two sunrise overlays... mtl-2 isn't anywhere at the moment, but I require mtl-1 so that when 2 shows up, nothing breaks. The parsec dep is taken care of by missingh? (no, I won't be offended if you commit your version instead)
> The parsec dep is taken care of by missingh? [speculation] As configfile uses parsec it should explicitely mention parsec as a dep. (It's not a transitional dep). Yes, it may seem to be redundant, but it helps a lot when one needs to find all direct reverse depends of parsec during major parsec upgrade. Another kind of troubles will arise when next version of missingH (and it's depends) will lose parsec depend (unlikely, but theoretically posible). [/speculation] Pushed to the tree almost in sunrise variant. Thanks Michael! What should I do to avoid duplication of an ebuild in sunrise?
(In reply to comment #6) > > As configfile uses parsec it should explicitely mention parsec as a dep. > (It's not a transitional dep). > Agreed, I just took another look at the cabal file and was mistaken to leave out the Parsec dependency. > What should I do to avoid duplication of an ebuild in sunrise? I think a Sunrise dev will remove it; I'll ask on IRC. Thanks!
The Gentoo-Haskell team has had a version of hmatrix in the haskell overlay since I first created it in August, 2008. As such, can the version in Sunrise please be removed to avoid confusion (I myself just spent about 15 minutes trying to work out why hmatrix was wrongly linking against dev-haskell/quickcheck before realising that the sunrise version was being used which doesn't disable the test support).
Maybe after two years it's time to commit it to the tree? Personally I would rather have it removed from the Haskell overlay; I hate that it seems like I need a new overlay for every single package I want to install these days. With it in Sunrise, there is a chance of it being moved to Portage eventually, and it's available to a wider audience. ..and I think this is the wrong bug =)
(In reply to comment #9) > Maybe after two years it's time to commit it to the tree? Is there a need for it to be in the tree? Will many people be wanting it, especially since it's a (relatively minimally used) library that no application in the tree needs? > Personally I would rather have it removed from the Haskell overlay; I hate that > it seems like I need a new overlay for every single package I want to install > these days. The only reason I can think of that you'd want configfile, etc. is because you want to do Haskell development. In which case, what's wrong with using the Haskell overlay (and it won't be for every single package a new overlay...) ? There are also more people able to fix bugs, etc. in the Haskell overlay than in the official Haskell herd. Note in particular that even your updated ebuild here is wrong: ConfigFile depends upon Parsec, and the ebuild doesn't have a dependency on it. Those of us who work with the Haskell overlay have a better understanding of how Haskell packaging works, and we even have some tools (mainly hackport) to assist us with these tasks. > With it in Sunrise, there is a chance of it being moved to Portage eventually, > and it's available to a wider audience. Ummm... I doubt that (on both counts). The first count, it's the Haskell herd that would be in charge of maintaining it in the tree if it gets there, and I'm sure they'd want to test it in the Haskell overlay first, not Sunrise. The latter: whilst more people probably use Sunrise than the Haskell overlay, how many people would actually want to install it? > ..and I think this is the wrong bug =) So why not actually put this in the right bug, if you knew it was the wrong one? And which _is_ the right bug?
Hmatrix and storable-complex are gone from Sunrise. (In reply to comment #10) > > Is there a need for it to be in the tree? Will many people be wanting it, > especially since it's a (relatively minimally used) library that no application > in the tree needs? Chicken and egg. Of course nothing in Portage needs it, because it isn't in Portage. > The only reason I can think of that you'd want configfile, etc. is because you > want to do Haskell development. In which case, what's wrong with using the > Haskell overlay (and it won't be for every single package a new overlay...) ? You can make the same argument for glibc, or half of the other packages in Portage. There are at least two people who wanted it, and it's likely there are more who just haven't bothered to write their own ebuilds and commit them to an official overlay. While "what's wrong with using an overlay..." is fine for one overlay, the problem is that *everyone* feels that way about *his* overlay. So now I have 8 overlays installed (one for nouveau, one for qemu-kvm, one for cairo-dock, one for hmatrix now...). At the office, when I need to add an overlay, I have to add it on ~20 machines. They add up. > There are also more people able to fix bugs, etc. in the Haskell overlay than > in the official Haskell herd. Note in particular that even your updated ebuild > here is wrong: ConfigFile depends upon Parsec, and the ebuild doesn't have a > dependency on it. Those of us who work with the Haskell overlay have a better > understanding of how Haskell packaging works, and we even have some tools > (mainly hackport) to assist us with these tasks. I don't doubt that you're more qualified to write the ebuilds; part of the reason I commit things to Sunrise is to get criticism and learn. I would just like to see the results available to the rest of us.
(In reply to comment #11) > Hmatrix and storable-complex are gone from Sunrise. > > (In reply to comment #10) > > > > Is there a need for it to be in the tree? Will many people be wanting it, > > especially since it's a (relatively minimally used) library that no application > > in the tree needs? > > Chicken and egg. Of course nothing in Portage needs it, because it isn't in > Portage. I think what Ivan means is that if the package is popular in the Haskell Community. Most packages from hackage obviously won't be in portage, as they are so many. Also, since we're basically only two people with commit rights to portage, we need to make sure to work on popular stuff. Looking at the reverse dependencies of hackage, it looks like only 12 packages depend on hmatrix. > While "what's wrong with using an overlay..." is fine for one overlay, the > problem is that *everyone* feels that way about *his* overlay. So now I have 8 > overlays installed (one for nouveau, one for qemu-kvm, one for cairo-dock, one > for hmatrix now...). At the office, when I need to add an overlay, I have to > add it on ~20 machines. They add up. I understand that it's inconvenient to use many overlays, but we've already got about 100 really popular packages in portage and that's quite a lot to maintain and keep high quality. > > There are also more people able to fix bugs, etc. in the Haskell overlay than > > in the official Haskell herd. Note in particular that even your updated ebuild > > here is wrong: ConfigFile depends upon Parsec, and the ebuild doesn't have a > > dependency on it. Those of us who work with the Haskell overlay have a better > > understanding of how Haskell packaging works, and we even have some tools > > (mainly hackport) to assist us with these tasks. > > I don't doubt that you're more qualified to write the ebuilds; part of the > reason I commit things to Sunrise is to get criticism and learn. I would just > like to see the results available to the rest of us. I'm glad you like to help out by writing ebuilds. You're always welcome to bump and add more stuff to the overlay, you'll get more feedback. But, until we've got more Gentoo Developers helping us maintaining portage, it's much easier to keep things in the overlay where more unofficial devs can help us.
