On Tue, Dec 25, 2007 at 10:17:09PM -0700, Richi Plana wrote: > On Tue, 2007-12-25 at 20:48 -0500, Jeffrey J. Kosowsky wrote: > > Axel Thimm wrote at about 17:51:47 +0200 on Monday, December 24, 2007: > > > In short: Go ahead and package uvc! I'll gladly help to iron out > > > anything that isn't clear. I'd start with gspcav1 as a template as v4l > > > kmdls have a long history and carry a lot of legacy constructs. > > > > Also, a style question. > > The uvc driver source is stored as a subversion project. > > Which of the following approaches to including the source code would > > you prefer. > > Option #1: I run subversion checkout manually and then create from > > that a source tarball for inclusion in the source rpm > > (perhaps labelled with the date as a suffix) > > > > Option #2: I set up the rpm to automatically download the source code > > from subversion at compile time. > > > > Also, let me know if you have any other suggestions here? > > Personally, I'd like to keep options in my spec file so the source is > configurable. Fedora people prefer a tarball and a clean spec (no extra > stuff for people who could actually use the additional features). Me, I > like additional features, so I suggest a spec that would be able to do > both depending on a flag passed to it. > > I think Fedorans want it clean because ... well, I'm not sure. Up to > you.
I would also suggest a prepackaged tarball, e.g. no knowledge of the underlying vcs to the package build. The reason is mainly reproducable builds. If for example you submit such a package and one wants to build it on some arch/distro you haven't yet, then you will not know whether any bugs coming up would be from the differing arch/distro or the newer sources. Also you may want to patch up the svn code and these patches applied to later checkouts may not apply anymore. One can argue that if one explicitly gives the revision tag, hg/git checksum etc one would avoid some of the reproducibility problems, but I still feel that it is better to have all bits already together. FWIW some builders are off the net, e.g. would not be able to even download the sources. Also sometimes cvs/svn services are not always available (see sf.net for example) making rebuilds more difficult. In short: I would have a one-liner that creates tarballs out of some vcs and put that in a comment above the Source0: line, while the Source0: should be a conventional tarball. That way one can still easily update the package to later sources by reapplying the commented tarball construction command. Next issue is what version to attach to a vcs checkout - I would always try to ask upstream about that and as a last resort use the checkout date, possibly with a "0." or similar prefixed to allow any "1.0" version to fit nicely into the upgrade path. -- Axel.Thimm at ATrpms.net
pgp5QKdCsVEBo.pgp
Description: PGP signature
_______________________________________________ atrpms-users mailing list [email protected] http://lists.atrpms.net/mailman/listinfo/atrpms-users
