Packaging Guidelines - creating tarball from VCS with script

Oron Peled oron at actcom.co.il
Tue May 15 20:30:27 UTC 2012


On Tuesday, 15 בMay 2012 17:40:27 Colin Walters wrote:
> On Tue, 2012-05-15 at 10:19 +0200, Tomas Radej wrote:
> 
> > Discussion with pingou and sochotni on #fedora-java brought us this: What 
about using an RPM macro with this grammar:
> > 
> > 	%create_tarball git|svn|cvs URL revision [additional commands]
> 
> The build system has no network access.

Yes, that's an important feature (so our sources are always rebuildable
regardless of extenal changes).

> For the present Fedora/Fedpkg/RPM architecture, you really can't get out
> of mashing git repositories into tarballs without a serious
> architectural rework of everything.

I think the real needed rework is not in the infrastructure, but
adding a new build mode to rpmbuild(1):

 * We currently have:
   1. The '-b[bsa]' build from .spec + sources
   2. The '-t[bsa]' build from tarball with embedded .spec
   3. The '--rebuild' build from SRPM

   Notes:
      - Modes 2, 3 actually extract the parts and continue as 1.

      - Both mode 1,2 can be used to generate SRPM which enable us
        to preserve all components in encapsulated form (no fuzzy
        external dependencies).

 * Which calls for two new modes:
   4. rpmbuild -b[bsa] --from-vcs-repo <url> spec_file
   5. rpmbuild -b[bsa] --from-vcs-wc <directory> spec_file

 * Notes:
   - Obviously mode 4 would be implemented in terms of mode 5
     (clone the URL to temporary wc and use it)

   - Just like mode 1 and 2 the '-bs' would enable us to encapsulate
     the result as SRPM that would not depend anymore in the vcs repo
     or wc -- this SRPM could be uploaded to koji, etc.

   - I think trying to abuse existing %prep section and %setup semantics
     for vcs use, will create more problems than it solves.

     My suggestion is that these command line flags could be used only
     if the .spec file also contains *alternative* %vcs_prep

 * Example:

    Name: acme
    ...
    Source0: %name-%version.tar.gz
    Patch0: foobar.patch
    ...
    Vcs-URL: git://something_we_can_clone_from

    # Would be used when no "--from-vcs-*" flags were given
    # e.g: when we --rebuild from SRPM
    %prep
    %setup
    %patch0 -p1

    # Would be only used for --from-vcs-repo
    %vcs_prep
    # No %setup (no tarballs here, move along)
    # No %patch (the vcs should be used for this)
    # Maybe we can have a nice macro for common cases
    %vcs_setup
    # Or alternatively, can be done manually
    git clone [some-special-flags-I-want] %{VCS_URL}

    # Both %prep and %vcs_prep would be skipped for --from-vcs-wc
    # Only the %_builddir would be set to the given directory

    # The rest is normal, since all execution paths now converge
    # into a "prepared" build directory + .spec file
    %build
    ...

Advantages:
 * All existing packages are unaffected (but --from-vcs-repo cannot
   be used with them yet).

 * A developer that work on a vcs-wc can create a package for testing
   imediately from her expanded wc.

 * A .spec file with the extra %vcs_prep and Vcs-URL can create SRPM
   directly from the vcs-repo. This SRPM can be uploaded to our
   build system and be used for building *without* any interaction
   with the vcs.

Problems:
 * The --from-vcs-wc is very handy and can be easily abused to generate
   RPM's from non-clean working trees:
   - Maybe this mode can mark some "dirty" flag in the RPM header.
     (RPM_WIP_UNRELEASED).

 * With --from-vcs-repo there is no clear model to separate "upstream"
   code from packager changes:
   - Maybe the solution is to map this information from the vcs.
     E.g:
       Vcs-URL-upstream: git://server/path master
       Vcs-URL-build:    git://server/path fc17

Now, is this a science fiction?

-- 
Oron Peled                                 Voice: +972-4-8228492
oron at actcom.co.il                  http://users.actcom.co.il/~oron
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


More information about the devel mailing list