public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox