| 1 |
On Tue, 29 Jan 2013 22:47:26 +0100 |
| 2 |
Pacho Ramos <pacho@g.o> wrote: |
| 3 |
|
| 4 |
> Also, autoformatting will help to prevent every package setting |
| 5 |
> messages with different lines length (in some cases really long lines |
| 6 |
> that I finally reported some bugs in the past to get them fitting in |
| 7 |
> "standard" 80 characters per line). |
| 8 |
|
| 9 |
I agree with you, there should be consistency as far as reasonable. |
| 10 |
Formatting certainly is a valid means. Some sort of <code> tags could |
| 11 |
be used if formatting isn't desired. Ie similar to eclass-manpages. |
| 12 |
|
| 13 |
|
| 14 |
The eclass blurb: |
| 15 |
readme.gentoo - An eclass for installing a README.gentoo doc file |
| 16 |
recording tips |
| 17 |
|
| 18 |
I know it started out as CONFIGURATION, but README.gentoo is generic |
| 19 |
enough to contain other package specific info a user or upstream |
| 20 |
developer might be interested in. What I have in mind right now are |
| 21 |
patches. |
| 22 |
|
| 23 |
This could look like the following in an ebuild: |
| 24 |
README_GENTOO_PATCHES=( "${FILESDIR}"/*.patch ) |
| 25 |
epatch "${README_GENTOO_PATCHES[@]}" |
| 26 |
|
| 27 |
Then the eclass generates for each patch in README_GENTOO_PATCHES a |
| 28 |
note within a standard section containing patch name, author, subject |
| 29 |
line. This needs something similar enough to a git format patch to |
| 30 |
magically work though, but might be a nice addition and would help the |
| 31 |
goal of consistency. Also git-format-patch like patches are anyway |
| 32 |
preferable to dangling patches with maybe a bug number in the ebuild |
| 33 |
at best. |
Archives