bug-grep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#17012: [3 PATCHES] Whitespace cleanup : Replace code-alignment tabs


From: Johannes Meixner
Subject: bug#17012: [3 PATCHES] Whitespace cleanup : Replace code-alignment tabs with spaces.
Date: Tue, 18 Mar 2014 10:02:04 +0100 (CET)
User-agent: Alpine 2.00 (LNX 1167 2008-08-23)


Hello,

On Mar 14 21:44 Jim Meyering wrote (excerpt):
On Fri, Mar 14, 2014 at 9:32 PM, Bruce Dubbs <address@hidden> wrote:
See the guidelines in coreutils' HACKING file.
...
Interesting.  Looking at the coreutils-8.22 tarball, there is no HACKING
file.  It's not in the coreutils-8.17 tarball either.  It is in the git tree
though.

FYI, that is deliberate.
You can get it here, too:

 http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING

If you're hacking on coreutils (as with most pkgs), you should be doing
so via a git clone, with the very latest, not starting from a tarball,
which is almost always out of date by at least a few commits.

I agree for real upstream developers (i.e. who work as authors).

But for casual external contributors it could be different:

In particular experienced users that have it installed as binary
software package from a (Linux) distributor (e.g. as RPM package).

Those users may find an issue and then install the matching source
package (e.g. a source RPM) so that they get the matching tarball
of their currently installed binary software, then change
that sources and provide a bugreport with patch to upstream.

I think it won't hurt when even the binary software package contains
such files as documentation. If for example coreutils' HACKING file
would be installed as documentation, at least some experienced users
may find and read it and contribute to upstream accordingly.

In general I think the installed documentation should be complete.

For example the coreutils README file could provide more specific
information how to contribute correctly to upstream.

My currently installed coreutils-8.22 README file
(from an openSUSE coreutils-8.22 RPM package) contains
------------------------------------------------------------------------
If you obtained this file as part of a "git clone", then see the
README-hacking file.  If this file came to you as part of a tar archive,
then see the file INSTALL for compilation and installation instructions.
...
Send bug reports, questions, comments, etc. to address@hidden
If you would like to suggest a patch, see the files README-hacking
and HACKING for tips.
------------------------------------------------------------------------
but I neither have README-hacking nor INSTALL nor HACKING installed.

Therefore the installed coreutils documentation looks incomplete from
my point of view regardless that it is probably considered correct
from upstream's point of view.

Perhaps this is a packaging issue because the openSUSE coreutils RPM
coreutils.spec file basically contains
------------------------------------------------------------------------
%install
...
make install DESTDIR="%buildroot" pkglibexecdir=%{_libdir}/%{name}
.
.
.
%files
...
%doc COPYING NEWS README THANKS
------------------------------------------------------------------------
see
https://build.opensuse.org/package/view_file/Base:System/coreutils/coreutils.spec?expand=1

According to the INSTALL file in my coreutils-8.22 tarball
a plain "make install" should do "the right thing":
------------------------------------------------------------------------
  4. Type `make install' to install the programs and any data files and
documentation. ------------------------------------------------------------------------

As far as I see it seems by default there is no documentation installed
(except man pages) which means that each coreutils distributor installs
a different set of documentation files.

I assume this is intended but I do not understand the reason behind.

By the way:
I wonder why is there no INSTALL file in the coreutils
git source repository at git://git.sv.gnu.org/coreutils

I assume all this is intended and there are good reasons for it
but from my point of view it looks somehow strange.


Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany
HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer





reply via email to

[Prev in Thread] Current Thread [Next in Thread]