[PATCH] Speed up modprobe and MAKEDEV

[Ralf Corsepius]

On Thu, 2008-10-09 at 13:37 -0700, Jesse Keating wrote:
> On Thu, 2008-10-09 at 22:26 +0200, Till Maas wrote:
> > On Thu October 9 2008, Jesse Keating wrote:
> > > On Thu, 2008-10-09 at 18:16 +0200, Till Maas wrote:
> > > > On Thu October 9 2008, Jesse Keating wrote:
> > > > > Only if we allow source repo tags to be a suitable source distribution
> > > > > method.  Since fedorahosted still doesn't have an easy to use way of
> > > > > distributing tarballs, and getting the code via a scm checkout is quite
> > > > > easy, it should suffice.
> > > >
> > > > If this is the only obstacle to get this done, I will write a patch for
> > > > Makefile.common that displays the URL for every file in sources to fetch
> > > > it from the lookaside cache. Then this URL can be provided as source
> > > > tarball on a fedorahosted wiki page.
> > >
> > > Why must we insist on tarballs?  Unless the tarball includes scm
> > > metadata in it, it's practically useless for upstream patch development.
> > 
> > Tarballs allow to easily build the desired software via rpm and test it. With 
> > make patch and make rediff and make prep from Makefile.common it is also 
> > pretty easy to create and update patches. I have sucessfully created patches 
> > for upstream using this. Using directly an upstream scm, it is always a PITA 
> > to make the spec build from there, because the spec needs to be heavily 
> > modificated or I have to remember to recreate the tarball everytime. It would 
> > like it very much, if this would be a lot easier, e.g. some intelligent 
> > macros in spec files that allow to use a scm instead of a tarball to be used 
> > as Source0 and some magic that allows to define what from the scm should be 
> > used, e.g. should uncommited changes be used?
> > 
> > Nevertheless, there have to be tarballs in the cvs lookaside cache, therefore 
> > it is not much work to link to them. Therefore I do not really see what needs 
> > to be discussed here. ;-)
> 
> I'm trying to see things from somebody else's point of view.  Recently,
> on this list, somebody else was arguing that we in Fedora land should be
> doing away with tarball distribution, and srpm distribution, and instead
> direct everything back to SCM, and to work on RPM so that it just
> understood SCM and left tarballs in the past.  Thank you for providing
> some argument against that (:
There are many more arguments against directly working from an SCM:
+ tarballs are easy to verify, long-term stable and easy to copy.
+ tarballs don't need a server infrastructure.
+ tarballs need a minimal client infrastructure.
+ tarballs decouple "rpms" from "upstreams".

That said, I find letting rpm directly work from SCMs to be
- unstable/unreliable
- unsafe/a security risk
- resource demanding
- adding too many project dependencies.

=> I actually hardly find an argument speaking for letting rpm work
directly from an SCM.

Ralf