From: Randy Dunlap <rdunlap@infradead.org>
To: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Rob Landley <rob@landley.net>,
Aaro Koskinen <aaro.koskinen@iki.fi>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Documentation/Changes: phase out Changes file that hasn't changed
Date: Wed, 24 Jul 2013 09:58:05 -0700 [thread overview]
Message-ID: <51F0079D.8060300@infradead.org> (raw)
In-Reply-To: <CAP=VYLqvxctQCmTqrdhtgrc1Fr1bfFGG-xn1RA68vUW6yWyG6w@mail.gmail.com>
On 07/23/13 17:32, Paul Gortmaker wrote:
> On Tue, Jul 23, 2013 at 7:10 PM, Rob Landley <rob@landley.net> wrote:
>> On 07/23/2013 05:57:15 PM, Aaro Koskinen wrote:
>>>
>>> Hi,
>>>
>>> On Sun, Jul 21, 2013 at 01:12:55AM -0400, Paul Gortmaker wrote:
>>>> Looking at the bigger picture, the need for this file has simply
>>>> passed. It was trying to detail required versions of userspace
>>>> packages, in order to cater to hand-crafted systems. But now the
>>>> majority of users get their userspace all at once from some kind
>>>> of distro, and we are probably a lot more serious about avoiding
>>>> breaking userspace than we were a dozen years ago.
>>
>>
>> You're right, there's no such thing as "embedded linux", nobody creates
>> their own hand-crafted systems, or assembles cross-compiling environments to
>> target hardware other than x86. That's crazy talk.
>
> Aside from the obvious sarcasm, what are you trying to say here? The above
> seems like a classic strawman argument to me, since _none_ of the above are
> things that I have said or implied. And if pressed, I can give many counter
> examples to drive that point home. Do I really need to?
>
>>
>>> Is there any file describing the needed tools (and minimum versions) to
>>> _build_ the kernel? I agree that trying to describe such for the run-time
>>> userspace does not belong to the kernel tree, but the required/supported
>>> versions of build tools should be still maybe documented...
>>
>>
>> Documentation/changes _is_ the file that describes the kernel's build-time
>> prerequisites. It hasn't changed in a while because we've been maintaining
>> backwards compatability, especially for several non-x86 targets where it's
>> fiddly to get newer toolchain versions.
>
> See the mail from hpa --- what may be the "latest" for some less common
> arch may also be simply too old for another arch. Hence this kind of stuff
> needs to be in an arch specific file, let alone not in a mis-named "Changes"
> file.
>
>>
>> (Personally I use the last GPLv2 releases of each package, so gcc 4.2.1,
>> binutils 2.17, make 3.81, and busybox.)
>
> And this works on every arch that linux supports?
>
>>
>> I agree squashfs and such aren't build time prerequisites. It might make
>> more sense to move some of these to menuconfig text for the appropriate
>> option. But that's not the same as not documenting it at all, and "this
>> document has been true for a long time and remains true, therefore we must
>> discard it" strikes me as a really weird document retention criteria.
>
> Again, a strawman. You suggest I said the above with your "this document..."
> quote, but I never said anything like that, and it totally mis-represents why I
> suggested we should remove it.
>
> Lets move forward from here and not descend into arguing over details.
>
> To that end, if we create a required-packages.txt that covers the generic
> stuff like "make" version, and then the arch specific stuff (in arch specific
> files) for key stuff like gcc version, and gas version, etc, would you not
> see that as an improvement over what is currently in the mis-named and
> largely abandoned Changes file?
Yes, a list of required packages with their locations (URLs) and other
metadata would be both Good and Sufficient IMO.
Thanks.
--
~Randy
next prev parent reply other threads:[~2013-07-24 16:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-21 5:12 [PATCH] Documentation/Changes: phase out Changes file that hasn't changed Paul Gortmaker
2013-07-23 22:57 ` Aaro Koskinen
2013-07-23 23:10 ` Rob Landley
2013-07-24 0:14 ` Randy Dunlap
2013-07-24 0:32 ` Paul Gortmaker
2013-07-24 16:58 ` Randy Dunlap [this message]
2013-07-24 0:34 ` Aaro Koskinen
2013-07-24 0:47 ` Paul Gortmaker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51F0079D.8060300@infradead.org \
--to=rdunlap@infradead.org \
--cc=aaro.koskinen@iki.fi \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paul.gortmaker@windriver.com \
--cc=rob@landley.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.