I do think that perhaps a reorganization of the directories is a good
idea. So that ppl who have limited space can easily rm -rf those parts
that they do not need. Patching might give them some errors, but it will
still patch the parts they do use.
You can't seperate the source tree with out also seperating the coders
that update it. All in all I think it should be left to the end user as to
which parts they do want and how they choose to get rid of what they don't
want.
On Fri, 27 Feb 1998, William Stearns wrote:
> On Thu, 26 Feb 1998, Jim Dennis wrote:
>
> > In a recent message to the list Mike Harris said:
> >
> > I don't mind downloading a 40M source tarball either, even if it
> > takes 6 days to compile. That's just my opinion however, and I'm
> >
> > which reminded me of a concern that I've had.
> >
> > Is our source tree getting large enough to consider some option
> > to split the full tree into "architecture subsets." If I just want
> > the x86 code would it be neat to be able to say:
> >
> > make archsubset x86
> >
> > ... to produce a tarball of just the x86 code?
>
> On a laptop with limited hard drive space I choose to delete the
> other architectures code blocks in arch/ and include/. Doing that saved
> 7-10MB. As it seemed to have no side effects, I put this feature into the
> "buildkernel"* script so that it automatically deletes code from other
> architectures than the one you're building on after it applies your
> patches (for this reason, the script is probably not useful for people who
> cross-compile).
> I know this isn't exactly what you were asking for, but maybe it's
> close enough to be useful to you and others.
>
> > (In this case we might even have some subsets of the x86 -- such
> > as GGI vs. non-GGI).
>
> If someone can suggest blocks of code to delete and under what
> architectures/conditions these blocks can be safely deleted, I'd be happy
> to incorporate those changes into buildkernel.
>
> As for the obvious question, "Will this reduce my download time?",
> the above tool can't affect that. If memory serves, having a
> "linux...i386.tar.gz" was discussed at one point and (rightfully, IMO),
> shot down. Two tars and two patches for each kernel is plenty on
> ftp.kernel.org and mirrors... Those who find the download time too long
> can still patch up from a base kernel.
> Cheers,
> - Bill
>
> * http://www.pobox.com/~wstearns/buildkernel/
>
> ---------------------------------------------------------------------------
> Unix _is_ user friendly. It's just very selective about who its friends
> are. And sometimes even best friends have fights.
> William Stearns (wstearns@pobox.com)
> ---------------------------------------------------------------------------
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu