On Thu, 2010-02-04 at 14:59 +0100, Loic Dachary wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jesse Keating wrote: > > On Tue, 2010-01-26 at 22:07 +0100, Loic Dachary wrote: Hi, > > > > Would you like to assist Jesse in publishing an updated jpoker > > package to fedora this week ? I assume Jesse will have some > > questions as the last version he worked on was 1.0.14 ;-) > > > > Cheers > >> > > > I've built 1.0.16 for Fedora Rawhide. Since the Makefile now has a > > build target, I switched to doing the build instead of copying > > pre-built stuff. As such, I could really use you guys testing it > > to see if it looks right. > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1960369 > > > I did run into a couple of issues. First, the tarball is quite > > huge. Not sure why, but there does seem to be a couple duplicate > > directories (jpoker-binary-$version), and these could probably be > > stripped from the source tarball. > > The idea is that the jpoker sources contain the complete set of files > needed > for development. This is ~3.5MB that consist mainly of 1.3MB for > jpoker itself (including tests) > and 2MB for the complete source distribution of jquery + jquery-ui. In > case this specific jquery-ui version is lost (the upstream does not > seem to care much about keeping old versions around), the > long term maintainance of the stable version is still possible.
Wait.. does this mean that we should have jquery and jquery-ui as separate packages? In Fedora, we don't really allow bundling other upstream projects in a package, we split them out and make use of them that way as individual packages. We don't have to worry about versions being lost as we have the package in our repo. > > There are two redundant directories: > > gems : these are the ruby gems dependencies and they are included in > the sources because there is no reliable way to ensure that a given > version (checksum for instance) is installed when the sources are > being compiled ( assembled with the tiddlywiki_cp gem for instance ). > In addition it is against the debian policy to pull sources from the > net because it would be a security risk (dependencies for a package > must be resolved by pulling packages from a Debian repository, not > from a random location elsewhere on the net). We have the same policy, which generally leads to having all our necessary required components available in the Fedora repository. We can express specific version requirements in our .spec file. It sounds like there are more things which need to be split off here. > > The jpoker-binary-* directory is a standalone minimal installation of > jpoker that does not rely on any external tools. It can be generated > from the sources, assuming you have the proper dependencies (inkscape, > ruby, make etc). As it turns out most of the people interested by > jpoker have no clue about these tools. They also have no interest in > developing and they want to deploy jpoker just by copying files. In > fact, the jpoker-binary directory is the usual way for JavaScript > developers to think about sources. The sources with the Makefile and a > generative process and a debian directory for packaging, is very > unusual. In a nutshell, the jpoker-binary-* is the source form > expected by JavaScript developers. It's also the source form that is > being uploaded to the jquery plugins catalogs. Yes, it is unfortunate the way that Java and JavaScript people think about "source" and development. Generally what we'd do is offer up what they are expecting in a "prebuilt" tarball. Then the actual sources and the Makefiles etc.. necessary to build those, with instructions on what other things you must have installed would go into the real source tarball. This makes it much easier for distributions, we no longer have risk of passing along something that was prebuilt, and when done this way we no longer have the risk of having other upstream things bundled in. > > The .hg makes sense because when you think of sources as the > "preferred form to work on a software", including the DVCS repository > is the best way to ship a self contained environment. Sure, that's fine. > > There are a mistake in the 1.0.16 distribution that makes it larger > than it should : usr. The usr directory is the side effect of running > make without argument. Ok I hoped that was all by accident. > > > Also, I had to patch jpoker-1.0.16/gems/bin/tiddlywiki_cp as it has > > a reference to /usr/bin/ruby1.8 which doesn't exist on Fedora, we > > just have /usr/bin/ruby > > I'm not sure how this could be resolved. The generation of the gems > directory occurs on a system where ruby is 1.8. I patched jpoker so that > > make RUBY=ruby > > overrides ruby1.8 with the provided command. No big deal, it's a trivial patch and easy to carry around. > > > If you need a build for another Fedora version in order to test, > > just let me know and I can do a "scratch" build (temporary > > unofficial build). > > In order to reduce the dependencies of jpoker and take advantage of > the fact that no real compilation is needed, you could install what's > in the jpoker-binary-* directory. The complex dependences (ruby etc) > can be set on the source package : they will be needed only by someone > willing to work on the sources anyway. Just a suggestion. Unfortunately that's not allowed in Fedora. We have to take the source and build it, we cannot re-use any prebuilt things. There are a multitude of reasons why, but bottom line it keeps us honest. Will there be somebody who can test these builds to make sure we're going down the right path, and if I have to split some things out ensure that it continues to function once split out? -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) identi.ca (http://identi.ca/jkeating)
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Pokersource-users mailing list [email protected] https://mail.gna.org/listinfo/pokersource-users
