seth vidal wrote:
On Wed, 2007-11-21 at 15:30 +0100, Jeroen van Meeuwen wrote:
seth vidal wrote:
3 years is a long time for keeping the sources around if we generate
them that way. It seems like we're better off in terms of space and in
terms of being able to provide sources for the longer run if we can
generate srpms on the fly out of cvs.
However once you choose to generate srpms on the fly out of cvs, you are
also committing to using cvs for the same amount of time. Migrating the
cvs component to anything else might show to have a huge tail and might
just not work in the sense that the new vcs might not give you srpms
with the same checksum, or <insert-favorite-unforeseen-hurdle-here>.
No we aren't committing to using cvs. We're committing to the tool
which generates the srpms being able to talk to whatever we're using in
the future.
I'm sorry I see now I shouldn't have used 'cvs' there but the point was
that we would need to be able to consistently generate the same file
over and over again. However while typing this message I read:
Matt Domsch wrote:
> And really, that's OK. We don't have to provide exactly the same
> SRPM. We have to provide the sources that went into the binary. If
> we provide that in a convenient SRPM form, that's fine - that's easy
> for our existing tools to consume. But we could post directories full
> of look-aside cache tarballs and patches if we wanted to.
So it seems the point is that it doesn't matter how or where from srpms
are being created (although it seems to me a spec file with some (in the
future, say 3 years from now- obsoleted tags will only be able to
generate a valid srpm by a fully backwards compatible RPM implementation
on the host, or we're gonna need to mock it all), and that we save space
if we do; provided this actually works now and does so for a long, long
period of time what's holding us back from trying to accomplish this
-regardless of FP actually distributing under 3b or not?
Kind regards,
Jeroen "archives everything anyway" van Meeuwen
-kanarip
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
