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@xxxxxxxxxxxx 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?
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
