On Wed, 2008-07-16 at 16:49 +0200, Nils Philippsen wrote:
> On Mon, 2008-07-14 at 08:28 -0800, Jeff Spaleta wrote:
> > On Sun, Jul 13, 2008 at 9:39 AM, Les Mikesell <lesmikesell@xxxxxxxxx> wrote:
> > > As long as the old method continues to work, what's the problem with adding
> > > a way to improve it going forward?
> >
> >
> > Yes, clearly there will need to keep something similar to the "old
> > method" around for dealing with tarball releases while this new
> > process moves forward. If we make the change, we'll have to support
> > both ways of doing it, and track the update on the new process on a
> > package by package basis.
> >
> > My largest concern continues to be source distribution. If we have to
> > support both models of packaging source control then I'm not sure what
> > our source distribution ends up looking like. Is it a mix of exploded
> > branches and srpms?
>
> IMO it should be SRPMS that contain a set of individual patches, just as
> what we have right now.
Well, as has been brought up in this discussion, we really are going to
have to end up supporting multiple formats because we really can't just
go and say to everyone "Look, switch to this new vcs setup for Fedora"
because there are those upstream projects where doing so would be
counterproductive.
In addition, I think Jeff's concerns (do you prefer Jeff or Jef, your
mail full name is one, your sig is the other...) can be split into two
distinctly different categories: the online fulfillment of the source
requirements of the GPL versus physical media fulfillment of the source
requirements of the GPL.
So, I think the matrix of answers to Jeff's concerns could actually be
drawn up as so:
On-Line On-Media
Fulfillment Fulfillment
Traditional SRPM style package Current dist-cvs SRPM package
+
look aside cache
Exploded source repo package On-line dist-* Tarball of
SCMs (could be package [1]
multiple types)
with exploded src
1 - Yeah, yeah, I know I've been harping about wanting to end the life
of tarballs, and I do, but as it turns out, for several technical
reasons, an exploded src repo is best distributed in a single version
format as an exported tarball from the scm. Included in the various
reasons why this is true is the fact that an exploded source repo that
has been tarballed up will in fact work with rpmbuild --rebuild
<tarball> or rpmbuild -t? <tarball> with only one modification needed to
rpmbuild. There is an inherent conflict between the exploded src repo
and a tarball/srpm in that an exploded source repo has no need of the %
setup macro, and without a %setup in %prep, it won't build as either an
srpm or tarball. However, given the specific nature of the tarball
special case code, it would actually be a rather simple change to have
the tarball special case code do an implicit %setup of the tarball it
was passed regardless of the presence of a %setup in %prep, and that
would then make tarball exports of an otherwise building exploded source
repo spec file work with 0 modifications necessary to the spec file, and
that preserves the concept that the tagged version of code in the scm
and the contents of the similarly versioned tarball are in fact byte for
byte identical. And given that the current tarball special case code
will break if you have anything *besides* %setup in %prep (well,
anything that needs additional sources unless they exists outside the
tarball already), and given that the %setup must reference the tarball
we were passed (or all sorts of nasty surprises can happen), the
implicit %setup change would not violate any principle of least surprise
changes in the rpmbuild code.
> > I'd also need to get an idea of what our local patchsets would look
> > like in the new cloned vcs packaging. I've had people tell me that
> > they very much prefer the style of different patch files as shipped in
> > our srpm delineated based on purpose and not necessarily a single
> > merged patch file that includes multiple changes. We are starting to
> > see the single patch files which are multiple patches merged into a
> > single patch and I've had someone complain specifically about it
> > being more difficult to understand.
>
> It should be possible (see Doug's comments about how kernel does it this
> way) to generate individual patches on top of a pristine tarball out of
> say a git repository. For packages that opted for this scheme, they
> could have their exploded repository which e.g. contained individual
> branches for each logical patch (stable and experimental ones), where
> you could cherry-pick the desired patches into a package release branch
> and have some tools that generated the patch files out of that (and
> possibly import it into the dist VCS which contained spec files and
> patches as usual).
The ultimate goal though would be to just educate people on using the
scm tools. We *could* export a bunch of patches into a separate vcs,
but that kind of defeats the purpose of trying to match our vcs to
upstream and doing cloned repos and what not ;-)
I don't really think it's that big of a problem though. Take for
instance the issue that Jesse addressed in this thread where he thought
the subtle finger pointing about doing a massive patch that was not so
open source community friendly was probably directed at grub. Not
withstanding the fact that the changes are basically a custom fork from
a dead package, and therefore there aren't many people interested in
going over them, he did mention that it was basically just a git export
to cvs. Which goes back to my assertion from the paragraph above that
if we aren't exporting from one scm to another, this sort of thing
doesn't happen (at least not as part of the export process anyway). And
the whole point would be non-existent if our grub repo were based on git
so we could just clone pjones' changes instead of exporting them. So,
I'll chalk this up as another reason why it's best not to export from
vcs to vcs, but to clone from upstream vcs to the same vcs here *when
possible and the packager doesn't mind changing to upstream's vcs*.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
