[PATCH] Speed up modprobe and MAKEDEV

[Daniel P. Berrange]

On Thu, Oct 09, 2008 at 01:37:14PM -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 (:

I like the tar.gz from a release tracking point of view - with pretty
much every distro, whether Linux, or BSD or Windows using pristine
tar.gz + patches, you can write some interesting tools to correlate
packages & patches across distros. I'm working on a toy/tool which 
would record the md5sum of every source & patch file from every 
released RPM in  Fedora, RHEL, Ubuntu, Debian, etc. It will also 
import checksums of official releases from major hosting sites like 
CPAN, gnome.org,  sourceforge etc. You can then correlate all the 
md5sums to track the relations between packages in different distros
vs upstream, even if the package naming is completely different. This
lets you answer questions like

 - What distros have at least version x.y.z 
 - When did version x.y.z appear in a distro
 - What packages are in distro A but not B
 - Is distro X out of date compared to latest upstream release
 - As a maintainer in distro A, what patches are other distros
   carrying against my packages
 - As an upstream maintainer, what patches are distros applying
   to my code.
 - As an app developer, if I have a choice between libraries A & B, 
   which is the most widely available in distros.
 - What source files claim to be version x.y.z, but don't match
   the x.y.z published by upstream (there's a number of surprises
   in this area, but in Fedora & CPAN itself :-)

There's probably more you can do, but those were the questions that 
motivated me to try and hack some cross-distro data corrrelation tool
together. Even if it doesn't turn into anything serious, its nice that
you can experiment with these kind of things. I fear it'd be harder to
do this kind of thing if everyone just bundled SCM repos in their distros
as source, as you'd need to actually get the source - currnetly I can 
just get the checksums from the 'sources' file in CVS without downloading
everything from the lookaside cache, likewise many hosting sites publish
the md5 sums separately from the sources. Then again maybe having the
full SCM repos would let you do some even more interesting correlation.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|