[gentoo-dev] Some 'proper coding' notes for ebuilds

[gentoo-dev] Some 'proper coding' notes for ebuilds

[Mike Frysinger]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 171 bytes --]

just a few notes ...
(1) checking $DEBUG and $DEBUGBUILD is wrong ... utilize `use debug`
(2) do not use spaces for indenting ... tabs are the standard
lub & kisses
-mike

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Mike Frysinger]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 436 bytes --]

On Saturday 02 August 2003 22:29, Mike Frysinger wrote:
> just a few notes ...
> (1) checking $DEBUG and $DEBUGBUILD is wrong ... utilize `use debug`
> (2) do not use spaces for indenting ... tabs are the standard
> lub & kisses
> -mike

oh, and instead of using $DEBUG and printing out debug related information, 
use the debug-* functions ... see kde.eclass for some *very* good examples of 
how to properly use them
-mike

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Mike Frysinger]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 211 bytes --]

oooooooooh and stop trying to run the `patch` cmd yourself ...

no one is cooler than `epatch` (which is integrated into portage now, so dont 
'inherit eutils'), so stop trying to think you ppl are

-mike

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Kumba]

Mike Frysinger wrote:

> oooooooooh and stop trying to run the `patch` cmd yourself ...
> 
> no one is cooler than `epatch` (which is integrated into portage now, so dont 
> 'inherit eutils'), so stop trying to think you ppl are
> 
> -mike

Isn't the only time we want to avoid this on a kernel ebuild?  There was 
an email many weeks ago on -dev I think (mighta been -core) which said 
to avoid using epatch on kernel sources, due to it's brute-force method. 
  Also, what about "xpatch"?  I had heard of this mechanism used awhile 
ago, but not recently.

--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Mike Frysinger]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 812 bytes --]

On Saturday 02 August 2003 22:50, Kumba wrote:
> Isn't the only time we want to avoid this on a kernel ebuild?  There was
> an email many weeks ago on -dev I think (mighta been -core) which said
> to avoid using epatch on kernel sources, due to it's brute-force method.
>   Also, what about "xpatch"?  I had heard of this mechanism used awhile
> ago, but not recently.

this was meant as a general heads up ... i'm sure the kernel team can handle 
the kernel ebuilds just fine themselves ;)

as for xpatch, i havent utilized it myself and havent looked into it ... right 
now 'epatch' is in portage, 'xpatch' is not ... it doesnt really matter too 
much since if we upgrade all packages to use epatch, we can easily switch 
over to 'xpatch'

pkgs that currently use xpatch:
app-text/a2ps
-mike

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]

On Sun, 2003-08-03 at 05:04, Mike Frysinger wrote:
> On Saturday 02 August 2003 22:50, Kumba wrote:
> > Isn't the only time we want to avoid this on a kernel ebuild?  There was
> > an email many weeks ago on -dev I think (mighta been -core) which said
> > to avoid using epatch on kernel sources, due to it's brute-force method.
> >   Also, what about "xpatch"?  I had heard of this mechanism used awhile
> > ago, but not recently.
> 
> this was meant as a general heads up ... i'm sure the kernel team can handle 
> the kernel ebuilds just fine themselves ;)
> 
> as for xpatch, i havent utilized it myself and havent looked into it ... right 
> now 'epatch' is in portage, 'xpatch' is not ... it doesnt really matter too 
> much since if we upgrade all packages to use epatch, we can easily switch 
> over to 'xpatch'
> 

I do not see why there should be two versions of the same thing.  If
epatch is broken, fix it ?


-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Mike Frysinger]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 276 bytes --]

On Sunday 03 August 2003 11:23, Martin Schlemmer wrote:
> I do not see why there should be two versions of the same thing.  If
> epatch is broken, fix it ?

i'd say talk to danarmark about it ... he wrote/utilizes it ...
personally epatch rubs me in that special way ;)
-mike

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Mamoru KOMACHI]

Hi,

At Sat, 2 Aug 2003 22:38:57 -0400,
Mike Frysinger wrote:

> oooooooooh and stop trying to run the `patch` cmd yourself ...

Agreed ;-)

> no one is cooler than `epatch` (which is integrated into portage now, so dont 
> 'inherit eutils'), so stop trying to think you ppl are

I'm afraid we should add 'inherit eutils' because though epatch is now
integrated into unstable version of portage, stable version of portage
(2.0.48-r5) doesn't have this functionality.  I came across the
problem in http://bugs.gentoo.org/show_bug.cgi?id=23131#c11 and found
we need 'inherit eutils' for stable.

Anyhow, some of the ebuilds seem to use epatch without 'inherit
eutils' (and I guess they will fail to compile properly).  I counted
that sort of ebuild using small sh script and it says 332 ebuilds use
epatch without declairing 'inherit eutlis' ;-( Well, I included both
stable and unstable ebuilds, but at least for stable we need to write
'inherit epatch' at this moment.

cf. here is the list of such ebuilds:

	http://dev.gentoo.org/~usata/ebuild_wepatch_woeutils.txt

-- 
Mamoru KOMACHI <usata@gentoo.org>
http://dev.gentoo.org/~usata/

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 699 bytes --]

On Sunday 03 August 2003 17:10, Mamoru KOMACHI wrote:
> Anyhow, some of the ebuilds seem to use epatch without 'inherit
> eutils' (and I guess they will fail to compile properly).  I counted
> that sort of ebuild using small sh script and it says 332 ebuilds use
> epatch without declairing 'inherit eutlis' ;-( Well, I included both
> stable and unstable ebuilds, but at least for stable we need to write
> 'inherit epatch' at this moment.

I didn't go through the list, but there are also eclasses that inherit eutils, 
and so provide epatch in an ebuild without it inheriting eutils.

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Mamoru KOMACHI]

Hi,

At Sun, 3 Aug 2003 17:40:27 +0200,
Paul de Vrieze wrote:

> I didn't go through the list, but there are also eclasses that inherit eutils, 
> and so provide epatch in an ebuild without it inheriting eutils.

Thank you for the comment. {games,kde,php,vim}.eclass use eutils
internally, so I excluded them, recalculated the ebuilds and got 

% wc -l ebuild_wepatch_woeutils.txt 264

I updated the list at
	http://dev.gentoo.org/~usata/ebuild_wepatch_woeutils.txt


regards,

-- 
Mamoru KOMACHI <usata@gentoo.org>
http://dev.gentoo.org/~usata/

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Georgi Georgiev]

On 04/08/2003 at 00:10:06(+0900), Mamoru KOMACHI used 1.1K just to say:
> I'm afraid we should add 'inherit eutils' because though epatch is now

An alternative would be to make the package depend on a later portage.

-- 
\    Georgi Georgiev   \  Don't confuse things that need action with   \
/     chutz@gg3.net    /  those that take care of themselves.          /
\   +81(90)6266-1163   \                                               \

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Mamoru KOMACHI]

Hi,

At Mon, 4 Aug 2003 01:27:41 +0900,
Georgi Georgiev wrote:

> An alternative would be to make the package depend on a later portage.

Yeah, I like the idea.  But the problem is portage 2.0.48 branch
(neither stable 2.0.48-r5 nor unstable 2.0.48-r7) doesn't have epatch
integrated into ebuild.sh, so it needs to be backported.  Maybe I
should file a bug report to dev-portage@g.o ;-)


regards,

-- 
Mamoru KOMACHI <usata@gentoo.org>
http://dev.gentoo.org/~usata/

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

On Sun, 2003-08-03 at 04:38, Mike Frysinger wrote:
> oooooooooh and stop trying to run the `patch` cmd yourself ...
> 
> no one is cooler than `epatch` (which is integrated into portage now, so dont 
> 'inherit eutils'), so stop trying to think you ppl are
> 

On a side note:  The whole idea of having epatch, etc in a eclass,
and not portage, was to be able to propagate fixes without a need
for a new portage.  If it really needs to be inside portage, can
portage just automatically inherit eutils.eclass (or whatever),
and not hardcode it ?


-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Patrick Kursawe]

[-- Attachment #1: Type: text/plain, Size: 721 bytes --]

On Sat, Aug 02, 2003 at 10:38:57PM -0400, Mike Frysinger wrote:
Content-Description: signed data
> oooooooooh and stop trying to run the `patch` cmd yourself ...
> 
> no one is cooler than `epatch` (which is integrated into portage now, so dont 
> 'inherit eutils'), so stop trying to think you ppl are

Too sad I can't remember the name, but a while ago someone discouraged
people from using epatch for simple patches because it's quite some
overkill...
If I have to apply just one or two patches, I don't see why I should not
run patch from the ebuild.

About inheriting: If you don't inherit, you should maybe better
DEPEND on the portage version which has it included.

Just my 0.02 EUR,

Patrick	

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Mike Frysinger]

On Monday 11 August 2003 09:45, Patrick Kursawe wrote:
> Too sad I can't remember the name, but a while ago someone discouraged
> people from using epatch for simple patches because it's quite some
> overkill...
> If I have to apply just one or two patches, I don't see why I should not
> run patch from the ebuild.

too many people just run 'patch < patchfile' without checking for whether it 
worked correctly ... plus, there are many ways to patch from gz/bzip2 (cat 
it, uncompress it, pipe it, blah blah blah) ...
running 'epatch <patch file>' standardizes patch handling in all ebuilds, plus 
developers dont have to worry about whether they did it correctly ... i know 
it took me a while to figure out how to apply a freakin patch over a src base 
:)

as for 'being overkill' ... yes, it has the ability to apply a ton of patches 
very easily, but if you just give it a patch file, it'll skip all that other 
code ... plus, if a patch fails, it shows nice output with a log file and 
everything ...

hands down, azarah pwned the patch cmd
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Jason A. Mobarak]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Frysinger wrote:
> On Saturday 02 August 2003 22:29, Mike Frysinger wrote:
> 
>>just a few notes ...
>>(1) checking $DEBUG and $DEBUGBUILD is wrong ... utilize `use debug`
>>(2) do not use spaces for indenting ... tabs are the standard
>>lub & kisses
>>-mike
> 
> 
> oh, and instead of using $DEBUG and printing out debug related information, 
> use the debug-* functions ... see kde.eclass for some *very* good examples of 
> how to properly use them
> -mike

Hey Mike, perhaps you should finalize all these coding standards into a 
document so you can refer people to it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/LJ5DVu24D/vyzbgRAn3jAJ9YP16Nhi0O2wkvy3Gtrz2MPgWSAwCgjBy7
71snxLIdfkisAi6P9cnQqoI=
=MOH8
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Mike Frysinger]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 351 bytes --]

On Sunday 03 August 2003 01:31, Jason A. Mobarak wrote:
> Hey Mike, perhaps you should finalize all these coding standards into a
> document so you can refer people to it.

i'm working on it ... i just felt that rather than telling devs to go re-read 
ebuild HOWTO docs every now and then wrong ...
just update them via the mailing list
-mike

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Unless I'm mistaken, most of this is in some document on the website 
already...

On Sunday 03 August 2003 05:31 am, Jason A. Mobarak wrote:
> Mike Frysinger wrote:
> > On Saturday 02 August 2003 22:29, Mike Frysinger wrote:
> >>just a few notes ...
> >>(1) checking $DEBUG and $DEBUGBUILD is wrong ... utilize `use debug`
> >>(2) do not use spaces for indenting ... tabs are the standard
> >>lub & kisses
> >>-mike
> >
> > oh, and instead of using $DEBUG and printing out debug related
> > information, use the debug-* functions ... see kde.eclass for some *very*
> > good examples of how to properly use them
> > -mike
>
> Hey Mike, perhaps you should finalize all these coding standards into a
> document so you can refer people to it.

- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/LKeaZl/BHdU+lYMRAlS7AJ9hmpNOwgpxdAwlCPlXpy7qsNusegCfY6RN
Xh3IoJkVVccNIqZyFKIFOes=
=Uuvi
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Stuart Herbert]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 572 bytes --]

On Sunday 03 August 2003 3:34 am, Mike Frysinger wrote:
> (2) do not use spaces for indenting ... tabs are the standard

Then the standard is broken, and needs updating.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
Beta packages for download            http://dev.gentoo.org/~stuart/packages/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 362 bytes --]

On Sun, 2003-08-03 at 16:55, Stuart Herbert wrote:
> On Sunday 03 August 2003 3:34 am, Mike Frysinger wrote:
> > (2) do not use spaces for indenting ... tabs are the standard
> 
> Then the standard is broken, and needs updating.

Reasoning ?


-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Stuart Herbert]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2233 bytes --]

'lo Martin,

On Sunday 03 August 2003 4:18 pm, Martin Schlemmer wrote:
> On Sun, 2003-08-03 at 16:55, Stuart Herbert wrote:
> > On Sunday 03 August 2003 3:34 am, Mike Frysinger wrote:
> > > (2) do not use spaces for indenting ... tabs are the standard
> >
> > Then the standard is broken, and needs updating.
>
> Reasoning ?

Because, in any non-trivial piece of code, indents can end up being a mixture 
of tabs and spaces, rather than just tabs.  When this happens, and you use a 
different tab size to the author, the indented code suddenly becomes a tad 
unreadable.

This page puts it a bit better (and stronger ;-) than I can:

	http://www.jwz.org/doc/tabs-vs-spaces.html

Additionally ...

There's no value in insisting on a particular indenting scheme.  A good coding 
standards document is a collection of technical review points to reduce the 
number of defects that make it into a source control system.  If a proposed 
standard has no effect on the defect rate, it doesn't belong in the coding 
standards document.  Period.

(Stuff like epatch over patch technically belongs in the design standards 
document - but it's common for design and coding standards to be combined 
into a single document out of ignorance).

And, seeing as there's no formal peer review of code committed to CVS anyway, 
<strong emphasis>you have no mechanism to enforce the entireity of any 
proposed standard</emphasis>.  Pitch the standard at stuff that actually 
makes a difference (like epatch over patch).

If you really want to enforce an indentation standard, run CVS checkins 
through indent or something.  Automate the mother.  That's how many 
commercial organisations manage that type of problem.

Sorry, I've been handling these issues for too many years in the day job.  
I'll take my SCM hat off now ;-)

Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
Beta packages for download            http://dev.gentoo.org/~stuart/packages/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Mike Frysinger]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 530 bytes --]

On Sunday 03 August 2003 14:07, Stuart Herbert wrote:
> Because, in any non-trivial piece of code, indents can end up being a
> mixture of tabs and spaces, rather than just tabs.  When this happens, and
> you use a different tab size to the author, the indented code suddenly
> becomes a tad unreadable.

historically all bash pieces of code have been taborized and if you look 
through the current tree, the vast majority are tabbed ...

the other reason i like tabs is we're looking at 1 byte vs 4 (or more) :)
-mike

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Stuart Herbert]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1028 bytes --]

On Sunday 03 August 2003 7:48 pm, Mike Frysinger wrote:
> historically all bash pieces of code have been taborized and if you look
> through the current tree, the vast majority are tabbed ...

Good for them ;-)

> the other reason i like tabs is we're looking at 1 byte vs 4 (or more) :)

Lots of laughter.  And how many extra pages on disk would be required if 
spaces were used instead of tabs? ;-)

Sorry, but your arguments aren't convincing me yet that

a) This belongs in the coding standards at all, and
b) That tabs are the way to do this

I guess I'm just a cantankerous old bugger, as we say over here ;-)

Take care,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
Beta packages for download            http://dev.gentoo.org/~stuart/packages/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[George Shapovalov]

Well, looks like there is no one around who remembers this thing, so I guess 
I'll chime in:

This (tabbed indentation) is indeed a policy. The resuidual indications of 
that can be found if you run lintool on some ebuild - it will complain about 
spaces before or after the line, tabs are ok (and are supposed to be used for 
indentation). While not really used nowadays, lintool is still a usefull 
tool, albeit unmaintained :(.  Repoman still does not have long-promised 
ebuild integrity checks (not all of them at least), therefore I would still 
recommend running lintool on new submissions and such (you just have to learn 
its (few) misreported features).

There has been a discussion of this issue, I believe over a year ago already. 
It has been decided that this indeed is a serious issue, worth being brought 
into the policy (main reason I beleive was to settle the never-ending 
debates). everybody agreed that it should be either all spaces or all tabs (I 
hope nobody would want it otherwise nowadays?) 
Upon weighting arguments thrown by bioth groups we have settled on all tabs. 
IIRC the deciding reason was that with tabs everyone is free to use their own 
level of indentation, while with spaces you are pretty much stuck with what 
particular developer used. Therefore we would have to enforce that particular 
aspect as well. Oh, should I mention that I am on a tabbed side ;)?

And on this account:
>Because, in any non-trivial piece of code, indents can end up being a mixture 
>of tabs and spaces, rather than just tabs.  When this happens, and you use a 
This is against a policy and is strictly forbidden. All ebuilds in the tree 
should only use tabs!

>different tab size to the author, the indented code suddenly becomes a tad 
>unreadable.
Above makes this a non-issue, and as I described in the beginning we do have 
that enforceent and we put it in place upon discussing alternatives and on 
purpose.

George

On Sunday 03 August 2003 11:53, Stuart Herbert wrote:
> Sorry, but your arguments aren't convincing me yet that
>
> a) This belongs in the coding standards at all, and
> b) That tabs are the way to do this
>
> I guess I'm just a cantankerous old bugger, as we say over here ;-)



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Stuart Herbert]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1733 bytes --]

On Sunday 03 August 2003 9:27 pm, George Shapovalov wrote:
> Well, looks like there is no one around who remembers this thing, so I
> guess I'll chime in:

;-)

> While not really used nowadays, lintool is still a
> usefull tool, albeit unmaintained :(.  

As a new developer, I've been told repeatedly that lintool is not worth using.  
Heck, it even says that in the Ebuild howto on the website, iirc.

> There has been a discussion of this issue, I believe over a year ago
> already. It has been decided that this indeed is a serious issue, worth
> being brought into the policy (main reason I beleive was to settle the
> never-ending debates). everybody agreed that it should be either all spaces
> or all tabs (I hope nobody would want it otherwise nowadays?)

Urgh ;-)

Although, I will admit, that most ebuilds are trivial enough to be indented 
using just tabs.

> Oh, should I mention that I am on a tabbed side ;)?

I'd never have guessed ;-)

> Above makes this a non-issue, and as I described in the beginning we do
> have that enforceent and we put it in place upon discussing alternatives
> and on purpose.

Second urgh.

What's next - forcing people to use emacs over vi, or vice versa? ;-)  
Seriously, I refer you back to my previous post about why engineers use 
coding standards.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
Beta packages for download            http://dev.gentoo.org/~stuart/packages/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[George Shapovalov]

On Sunday 03 August 2003 13:34, Stuart Herbert wrote:
> On Sunday 03 August 2003 9:27 pm, George Shapovalov wrote:
> As a new developer, I've been told repeatedly that lintool is not worth
> using. Heck, it even says that in the Ebuild howto on the website, iirc.
and
>Warning: Be warned - lintool is very broken. Use repoman instead.

Sure, don't use lintool *instead* of repoman (just trying to clarify so that 
nobody will take my words out of context (Stuart: not directed at you 
personally, as I am sure you understood what I meant ;))). However I still 
find lintool quite usefull for a basic ebuild composition checks, it seems to 
catch a bit more of those. 

I would say use both, with repoman taking precedence where they contradict 
(although I never saw this happen). I usually run ebuilds through lintool 
first (you *will* get few false errors/warnings, so you need to know the tool 
and the policy :)) and when everything ready run repoman on a dir..
Although clearly use of lintool *is not required* anymore..

George



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Don Seiler]

On Sun, Aug 03, 2003 at 03:15:55PM -0700, George Shapovalov wrote:
> However I still 
> find lintool quite usefull for a basic ebuild composition checks, it seems to 
> catch a bit more of those. 

Can repoman not be updated to catch what only lintool catches now, so
that we can have our all-in-one kwik-e-tool?

Don.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Anthony de Boer]

Don Seiler wrote:
> Can repoman not be updated to catch what only lintool catches now, so
> that we can have our all-in-one kwik-e-tool?

The implication I see in the documentation is that repoman is for Gentoo
developers only[0], and implies you need CVS access to the Gentoo tree,
while one shouldn't bother with lintool at all[1].  As a non-dev wanting
to submit the occasional ebuild, I'd like a tool I can use to make sure
I don't miss anything obvious that a CVS committer would see when he/she
runs repoman against my ebuild.

Hmmm, now I'm wondering what'd happen if I put my ebuilds in a local CVS
repository; would repoman know it wasn't the "real" repository?  If that's
the case, the manpage should probably give a pointer about doing that,
and not start off by scaring away non-devs.

[0] repoman(1) says:
  repoman is meant for Gentoo developers only due to the fact it does not
  work on a per-ebuild basis.  It checks the quality of CVS repositories.
  If you want some utility to check out the quality  of  ebuilds,  emerge
  dev-util/lintool.

[1] http://www.gentoo.org/doc/en/gentoo-howto.xml repeatedly says
``Be warned - lintool is very broken. Use repoman instead.''

-- 
Anthony de Boer

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

On 08/08/03  Anthony de Boer wrote:

> Don Seiler wrote:
> > Can repoman not be updated to catch what only lintool catches now,
> > so that we can have our all-in-one kwik-e-tool?
> 
> The implication I see in the documentation is that repoman is for
> Gentoo developers only[0], and implies you need CVS access to the
> Gentoo tree, while one shouldn't bother with lintool at all[1].  As a
> non-dev wanting to submit the occasional ebuild, I'd like a tool I can
> use to make sure I don't miss anything obvious that a CVS committer
> would see when he/she runs repoman against my ebuild.
> 
> Hmmm, now I'm wondering what'd happen if I put my ebuilds in a local
> CVS repository; would repoman know it wasn't the "real" repository? 
> If that's the case, the manpage should probably give a pointer about
> doing that, and not start off by scaring away non-devs.

Have a look at 
http://forums.gentoo.org/viewtopic.php?t=59389 , I posted a repoman
version there that works on a local portage tree (the main tree or your
overlay).

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[George Shapovalov]

On Friday 08 August 2003 08:21, Anthony de Boer wrote:
> Don Seiler wrote:
> > Can repoman not be updated to catch what only lintool catches now, so
> > that we can have our all-in-one kwik-e-tool?
> The implication I see in the documentation is that repoman is for Gentoo
> developers only[0], and implies you need CVS access to the Gentoo tree,
> while one shouldn't bother with lintool at all[1].  As a non-dev wanting
> to submit the occasional ebuild, I'd like a tool I can use to make sure
> I don't miss anything obvious that a CVS committer would see when he/she
> runs repoman against my ebuild.

I would like to second that. Even as a developer I like to do two passes - 
first is done with lintool, while I tweak an ebuild in my "live" tree (and I 
do have them separate, - gives me quite a bit of flexibility in tweaking 
without a risk of inadvertedly committing some local changes to the global 
tree) and then using repoman to finalize all "distributed" stuff, like 
digests, etc. in the cvs tree. Nothing beats lintool (so far and if you know 
your way around it) for the first checks that involve the ebuild itself..

George



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Douglas Russell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 08 August 2003 7:25 pm, George Shapovalov wrote:
> On Friday 08 August 2003 08:21, Anthony de Boer wrote:
> > Don Seiler wrote:
> > > Can repoman not be updated to catch what only lintool catches now, so
> > > that we can have our all-in-one kwik-e-tool?
> >
> > The implication I see in the documentation is that repoman is for Gentoo
> > developers only[0], and implies you need CVS access to the Gentoo tree,
> > while one shouldn't bother with lintool at all[1].  As a non-dev wanting
> > to submit the occasional ebuild, I'd like a tool I can use to make sure
> > I don't miss anything obvious that a CVS committer would see when he/she
> > runs repoman against my ebuild.
>
> I would like to second that. Even as a developer I like to do two passes -
> first is done with lintool, while I tweak an ebuild in my "live" tree (and
> I do have them separate, - gives me quite a bit of flexibility in tweaking
> without a risk of inadvertedly committing some local changes to the global
> tree) and then using repoman to finalize all "distributed" stuff, like
> digests, etc. in the cvs tree. Nothing beats lintool (so far and if you
> know your way around it) for the first checks that involve the ebuild
> itself..
>
> George
>
>
>
> --
> gentoo-dev@gentoo.org mailing list

I've been looking into integrating the lintool functionality into repoman for 
the last couple of days, am beginning to make some headway. I will let you 
know where I've got something worth looking at.

I'm aware that lintool is "broken", but nobody seems to know exactly what is 
wrong with it. This would help enoumously if someone could enlighten me...

Cheers.

Puggy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/M/cpXYnvgFdTojMRAgwkAKCDbQ67dMKkG/J5RkS/JZoYBi1MzQCgrIUV
qJO+bL2lx8HqhlqsIVkgPgk=
=Azch
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[George Shapovalov]

On Friday 08 August 2003 12:16, Douglas Russell wrote:
> I've been looking into integrating the lintool functionality into repoman
> for the last couple of days, am beginning to make some headway. I will let
> you know where I've got something worth looking at.
>
> I'm aware that lintool is "broken", but nobody seems to know exactly what
> is wrong with it. This would help enoumously if someone could enlighten
> me...

It isn't actually broken that much. This is the one I am getting every time:
* Testing for malformed headers                                      : failed
- (W) Has illegal or suspect headers:
- (E) Missing Copyright statement

This is due to 2003 not being in the list of "valid years".

The main reason why lintool is deprecated is that it only performs 
ebuild-specific checks, i.e. no digest checking or, perheaps the main 
problem, no dependency checking, like repoman does. The deprecation was 
really put to force everybody use repoman from what I remember. Although I 
would appreciate having an *additional* ebuild-specific tool - I find it 
useful to have the ability to do easy preliminary checks on submitted stuff..
(that is to say, I would personally appreciate having lintool around if 
possible, just make sure everybody understands that *this is not a 
substitute* for repoman!). But having lintool checks incorporated in repoman 
is definitely usefull for those who do not want to bother with multiple 
tools..

George



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Mike Frysinger]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 131 bytes --]

hopefully lintool will be cleaned up and ready to go in the nearish future ... 
karltk and myself are workin on it atm :)
-mike

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[George Shapovalov]

On Friday 08 August 2003 13:12, George Shapovalov wrote:
> > I'm aware that lintool is "broken", but nobody seems to know exactly what
> > is wrong with it. This would help enoumously if someone could enlighten
> > me...
> It isn't actually broken that much. This is the one I am getting every
> time: * Testing for malformed headers                                     

Oh, forgot this one:
- (W) Has illegal space characters (marked by %):
 |[line 34]:%

while in reality that line # is 35. "1" gets eaten somewhere, perheaps array 
index (which starts at 0) is used instead of "real" line number.

George



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Aron Griffis]

Stu,

Stuart Herbert wrote:	[Sun Aug 03 2003, 04:34:58PM EDT]
> What's next - forcing people to use emacs over vi, or vice versa? ;-)
> Seriously, I refer you back to my previous post about why engineers
> use coding standards.

While I agree with you (and jwz) regarding coding standards, and
tabs-vs-spaces, I clearly remember the discussion from a year ago.  Tabs
are the rule for indenting ebuilds.  (I don't mind the thought of the
rule changing eventually, but at the moment the rule stands.)

Aron

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some 'proper coding' notes for ebuilds

[Stuart Herbert]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 763 bytes --]

On Sunday 03 August 2003 9:35 pm, Spider wrote:
>   I for one use a variable width font in terminals, 

That should be your problem, surely? :P

> (What! you dont use the portage lint tool to check your builds?  Bad
> boy. )

Quoting from http://www.gentoo.org/doc/en/gentoo-howto.xml:

	Warning: Be warned - lintool is very broken. Use repoman instead.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
Beta packages for download            http://dev.gentoo.org/~stuart/packages/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]