[gentoo-dev] common ebuild mistakes

[gentoo-dev] common ebuild mistakes

[Alastair Tse]

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

Hi,

I've written up a list of common mistakes that users make when
submitting ebuilds to us for inclusion. This stems from the discussion
earlier on the list about the quality of user-submitted ebuilds.

http://cvs.gentoo.org/~liquidx/ebuildmistakes.html

The document is based solely on my point of view and the ebuilds that
are submitted to areas that I help maintain. If you are planning to
submit an ebuild (or already have), please review the points in this
document and make sure are not committing any of those mistakes.

If this proves to be useful, I will talk to the docs team about making
some effort for an official ebuild submission QA checklist (or something
along those lines.) To be honest, a lot of the points are already
covered in the Ebuild HOWTO and Development policy.

Cheers,

-- 
Alastair 'liquidx' Tse
 >> Gentoo Developer 
 >> http://www.liquidx.net/ | http://cvs.gentoo.org/~liquidx/
 >> GPG Key : http://cvs.gentoo.org/~liquidx/liquidx_gentoo_org.asc
 >> FingerPrint : 579A 9B0E 43E8 0E40 EE93  BB1C 38CE 1C7B 3907 14F6

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

Re: [gentoo-dev] common ebuild mistakes

[Dylan Carlson]

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

On Thu May 22 2003 9:30 pm, Alastair Tse wrote:
> Hi,
>
> I've written up a list of common mistakes that users make when
> submitting ebuilds to us for inclusion. This stems from the discussion
> earlier on the list about the quality of user-submitted ebuilds.
>
> http://cvs.gentoo.org/~liquidx/ebuildmistakes.html
>

This is excellent, Alastair.   It's been my experience that most 
user-submitted ebuilds would get checked in much faster (probably in half 
the time) if people followed the guidelines described there.

This should be made an official document up on www.

Cheers,
Dylan Carlson
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F
Key fingerprint = 3AEA DE38 FE42 15A6 C0E2 730E 3D04 BCC1 708E 165F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+zcZJPQS8wXCOFl8RApJwAJ40Fecu9duUkiu+43RkE7UeqpMmWACfcH0n
pJSUR6GyyRwCXcqt/pg8B5E=
=FXBu
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] common ebuild mistakes

[Georgi Georgiev]

On Fri, May 23, 2003 at 02:57:05AM -0400, Dylan Carlson wrote:
> This is excellent, Alastair.   It's been my experience that most 
> user-submitted ebuilds would get checked in much faster (probably in half 
> the time) if people followed the guidelines described there.
> 
> This should be made an official document up on www.

Even better, it could be shown each time a user submits a new ebuild.  Don't
know how easy to implement in bugzilla it may be, but it would be real helpful
even if it is displayed every time. Some may think it is annoying, but I don't.
People don't submit ebuilds all too often anyway.

-- 
 /^^^^^^^^^^^^^^^^^^^^^^^^^^^\/^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\
/ Georgi Georgiev    (-<     / There are three things I always  \
\ chutz@chubaka.net  /\   .o)\ forget. Names, faces -- the      /
/ +81(90)6266-1163  V_/_ |(/)/ third I can't remember. -- Italo \
\                   ^^^^^^^^^\ Svevo                            /
 \___________________________/\________________________________/

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] common ebuild mistakes

[Sven Vermeulen]

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

On Fri, May 23, 2003 at 08:13:19PM +0900, Georgi Georgiev wrote:
> People don't submit ebuilds all too often anyway.

http://bugs.gentoo.org/buglist.cgi?query_format=&short_desc_type=regexp&short_desc=new.*%28ebuild%7Cpackage%29&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=NEW&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=1&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

New ebuilds in the last day (yes, 1 day): 33 bugs found. Perhaps 3 of them
aren't really new ebuilds but just matched the regexp.

Wkr,
	Sven Vermeulen
	Gentoo Documentation

-- 
Thanks to DRM, you know that something has been built in environment of 
unspecified degree of security, from source you cannot check, written by 
programmers you don't know, released after passing QA of unknown quality and 
which is released under a license that disclaims any responsibility...

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

Re: [gentoo-dev] common ebuild mistakes

[Paul de Vrieze]

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

On Friday 23 May 2003 03:30, Alastair Tse wrote:
> Hi,
>
> I've written up a list of common mistakes that users make when
> submitting ebuilds to us for inclusion. This stems from the discussion
> earlier on the list about the quality of user-submitted ebuilds.
>
> http://cvs.gentoo.org/~liquidx/ebuildmistakes.html
>
> The document is based solely on my point of view and the ebuilds that
> are submitted to areas that I help maintain. If you are planning to
> submit an ebuild (or already have), please review the points in this
> document and make sure are not committing any of those mistakes.
>
> If this proves to be useful, I will talk to the docs team about making
> some effort for an official ebuild submission QA checklist (or something
> along those lines.) To be honest, a lot of the points are already
> covered in the Ebuild HOWTO and Development policy.

I've got some aditional points for submitters:

- Please base the update on the latest ebuild in the portage tree, not your 
own version. This is sometimes a problem with people who submit updates to a 
package that they made the initial ebuild for. Those ebuilds are often 
cleaned up, but with new versions you still get the same ebuild as the 
initial one instead of an edited version of the official ebuild

- Please please, do not submit ebuilds for version bumps unless necessary and 
if necessary tell us what changed.

Paul

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

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

Re: [gentoo-dev] common ebuild mistakes

[Dhruba Bandopadhyay]

Paul de Vrieze wrote:
> - Please please, do not submit ebuilds for version bumps unless necessary and 
> if necessary tell us what changed.

Version bump only when necessary?  What does this mean?  Isn't keeping 
up to date a basic requirement to maintain a modern tree?


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] common ebuild mistakes

[Henti Smith]

On Fri, 23 May 2003 13:01:26 +0100
Dhruba Bandopadhyay <dhruba@codewordt.co.uk> wrote:

> Paul de Vrieze wrote:
> > - Please please, do not submit ebuilds for version bumps unless necessary and 
> > if necessary tell us what changed.
> 
> Version bump only when necessary?  What does this mean?  Isn't keeping 
> up to date a basic requirement to maintain a modern tree?

I agree .... if this was that case I would still be using slackware or something since I can "update" the packaes I have installed when "needed" 
I use gentoo so I can get the latest mplayer a few days after it comes out etc etc 

otherwise whats the point of having gentoo and portage .. ? 

Henti 

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] common ebuild mistakes

[Georgi Georgiev]

On Fri, May 23, 2003 at 01:52:32PM +0200, Henti Smith wrote:
> I agree .... if this was that case I would still be using slackware or
> something since I can "update" the packaes I have installed when "needed" I
> use gentoo so I can get the latest mplayer a few days after it comes out etc
> etc 
> 
> otherwise whats the point of having gentoo and portage .. ? 

That's one thing I hear lots of people pointing as a downside of gentoo. In an
attempt to have the newest packages it happens that even the stable ones are
not stable enough.

I thought the idea of portage is the ability to compile the packages any way
you want, not necessarily to have the newest one a few days after it's out.

Otherwize, even RedHat had pretty fresh packages in its Rawhide for the
adventurous. And not that late after the official release at all.

-- 
 /^^^^^^^^^^^^^^^^^^^^^^^^^^^\/^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\
/ Georgi Georgiev    (-<     / When I was 16, I thought there   \
\ chutz@chubaka.net  /\   .o)\ was no hope for my father. By    /
/ +81(90)6266-1163  V_/_ |(/)/ the time I was 20, he had made   \
\                   ^^^^^^^^^\ great improvement.               /
 \___________________________/\________________________________/

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] common ebuild mistakes

[Henti Smith]

On Fri, 23 May 2003 21:15:07 +0900
Georgi Georgiev <chutz@gg3.net> wrote:

> On Fri, May 23, 2003 at 01:52:32PM +0200, Henti Smith wrote:
> > I agree .... if this was that case I would still be using slackware or
> > something since I can "update" the packaes I have installed when "needed" I
> > use gentoo so I can get the latest mplayer a few days after it comes out etc
> > etc 
> > 
> > otherwise whats the point of having gentoo and portage .. ? 
> 
> That's one thing I hear lots of people pointing as a downside of gentoo. In an
> attempt to have the newest packages it happens that even the stable ones are
> not stable enough.

I don't mind unstable stuff ... before gentoo I compiled everything myself as well 
and I run my system as ~x86 and I edit packages.mask and have portage overlay for my own bumps thats not in 
portage yet.

> I thought the idea of portage is the ability to compile the packages any way
> you want, not necessarily to have the newest one a few days after it's out.

There are many sides to what gentoo offers .. for me personally .. it's the fact that I can install the latest stuff to play with
and I don't have to worry about dependancies ... if there is a problem .. I write my own ebuilds to do what I want and sort it out and 
submit it .. 

> Otherwize, even RedHat had pretty fresh packages in its Rawhide for the
> adventurous. And not that late after the official release at all.

I like to compile stuff ;P 

Henti 

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] common ebuild mistakes

[Jon Portnoy]

On Fri, May 23, 2003 at 09:15:07PM +0900, Georgi Georgiev wrote:
> On Fri, May 23, 2003 at 01:52:32PM +0200, Henti Smith wrote:
> > I agree .... if this was that case I would still be using slackware or
> > something since I can "update" the packaes I have installed when "needed" I
> > use gentoo so I can get the latest mplayer a few days after it comes out etc
> > etc 
> > 
> > otherwise whats the point of having gentoo and portage .. ? 
> 
> That's one thing I hear lots of people pointing as a downside of gentoo. In an
> attempt to have the newest packages it happens that even the stable ones are
> not stable enough.
> 
> I thought the idea of portage is the ability to compile the packages any way
> you want, not necessarily to have the newest one a few days after it's out.
> 
> Otherwize, even RedHat had pretty fresh packages in its Rawhide for the
> adventurous. And not that late after the official release at all.
> 

We want our ~arch keyworded ebuilds to be as up to date as possible.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] common ebuild mistakes

[Jon Portnoy]

On Fri, May 23, 2003 at 01:52:32PM +0200, Henti Smith wrote:
> On Fri, 23 May 2003 13:01:26 +0100
> Dhruba Bandopadhyay <dhruba@codewordt.co.uk> wrote:
> 
> > Paul de Vrieze wrote:
> > > - Please please, do not submit ebuilds for version bumps unless necessary and 
> > > if necessary tell us what changed.
> > 
> > Version bump only when necessary?  What does this mean?  Isn't keeping 
> > up to date a basic requirement to maintain a modern tree?
> 
> I agree .... if this was that case I would still be using slackware or something since I can "update" the packaes I have installed when "needed" 
> I use gentoo so I can get the latest mplayer a few days after it comes out etc etc 
> 
> otherwise whats the point of having gentoo and portage .. ? 
> 
> Henti 
> 
> --
> gentoo-dev@gentoo.org mailing list

I missed most of this thread due to time constraints and may be just 
jumping in at the wrong place, but as a matter of policy, version bumps 
are always a plus.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] common ebuild mistakes

[Patrick Kursawe]

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

On Fri, May 23, 2003 at 01:01:26PM +0100, Dhruba Bandopadhyay wrote:
> >- Please please, do not submit ebuilds for version bumps unless necessary 
> >and if necessary tell us what changed.
> 
> Version bump only when necessary?  What does this mean?  Isn't keeping 
> up to date a basic requirement to maintain a modern tree?

That means: If you just copied the ebuild and did not edit it, don't
attach it.

Bye, Patrick

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

Re: [gentoo-dev] common ebuild mistakes

[Dhruba Bandopadhyay]

Patrick Kursawe wrote:
> On Fri, May 23, 2003 at 01:01:26PM +0100, Dhruba Bandopadhyay wrote:
> 
>>>- Please please, do not submit ebuilds for version bumps unless necessary 
>>>and if necessary tell us what changed.
>>
>>Version bump only when necessary?  What does this mean?  Isn't keeping 
>>up to date a basic requirement to maintain a modern tree?
> 
> 
> That means: If you just copied the ebuild and did not edit it, don't
> attach it.
> 
> Bye, Patrick

Thanks for clarification.  That makes sense.  I usually try the renamed 
ebuild in portage overlay and add a comment to the bug saying it worked 
without attaching it.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] common ebuild mistakes

[Paul de Vrieze]

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

On Friday 23 May 2003 14:12, Dhruba Bandopadhyay wrote:
>
> Thanks for clarification.  That makes sense.  I usually try the renamed
> ebuild in portage overlay and add a comment to the bug saying it worked
> without attaching it.
>

Many people do that, and that was what I meant. There are people though who 
don't and also don't mention it is just a copy. They leave it for the 
developer to find out whether the ebuilds are the same.

Paul

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

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

Re: [gentoo-dev] common ebuild mistakes

[Alastair Tse]

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

On Fri, 2003-05-23 at 13:01, Dhruba Bandopadhyay wrote: 
> Paul de Vrieze wrote:
> > - Please please, do not submit ebuilds for version bumps unless necessary and 
> > if necessary tell us what changed.
> 
> Version bump only when necessary?  What does this mean?  Isn't keeping 
> up to date a basic requirement to maintain a modern tree?

I think what Paul means is:

If you submit a bug about a package needing a version bump, only
_attach_ the ebuild if something needs to be changed in the _ebuild_ to
support the new version.

Cheers,
-- 
Alastair 'liquidx' Tse
 >> Gentoo Developer
 >> http://www.liquidx.net/ | http://cvs.gentoo.org/~liquidx/
 >> GPG Key : http://cvs.gentoo.org/~liquidx/liquidx_gentoo_org.asc
 >> FingerPrint : 579A 9B0E 43E8 0E40 EE93  BB1C 38CE 1C7B 3907 14F6

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

Re: [gentoo-dev] common ebuild mistakes

[Martin, Stephen]

Paul de Vrieze wrote:
> 
> - Please base the update on the latest ebuild in the portage tree, not your 
> own version. This is sometimes a problem with people who submit updates to a 
> package that they made the initial ebuild for. Those ebuilds are often 
> cleaned up, but with new versions you still get the same ebuild as the 
> initial one instead of an edited version of the official ebuild
> 
> - Please please, do not submit ebuilds for version bumps unless necessary and 
> if necessary tell us what changed.

I've a couple of questions about this.  Last night I emerged mplayer and 
noticed that aalib didn't get installed even though I had it in USE. 
Obviously, fixing this is a trivial change to the RDEPEND section of the 
ebuild (aalib is autodetected by mplayer and so no change to $myconf is 
necessary).  What's the best way to handle small changes like this? 
Should I just file a bug and state what needs to be done, or should I 
file a bug and attach a diff?  Is there a rule of thumb for how large a 
change has to be in order to warrant a diff or ebuild?

-- 
Stephen Martin

PGP/GnuPG key 1024D/8C4FCA5D


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] common ebuild mistakes

[Paul de Vrieze]

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

On Friday 23 May 2003 21:15, Martin, Stephen wrote:
> Paul de Vrieze wrote:
> > - Please base the update on the latest ebuild in the portage tree, not
> > your own version. This is sometimes a problem with people who submit
> > updates to a package that they made the initial ebuild for. Those ebuilds
> > are often cleaned up, but with new versions you still get the same ebuild
> > as the initial one instead of an edited version of the official ebuild
> >
> > - Please please, do not submit ebuilds for version bumps unless necessary
> > and if necessary tell us what changed.
>
> I've a couple of questions about this.  Last night I emerged mplayer and
> noticed that aalib didn't get installed even though I had it in USE.
> Obviously, fixing this is a trivial change to the RDEPEND section of the
> ebuild (aalib is autodetected by mplayer and so no change to $myconf is
> necessary).  What's the best way to handle small changes like this?
> Should I just file a bug and state what needs to be done, or should I
> file a bug and attach a diff?  Is there a rule of thumb for how large a
> change has to be in order to warrant a diff or ebuild?

It is a matter of personal judgement when to submit full ebuilds, when diffs 
and when nothing (except a description). By the way, myconf should still be 
used to explicitly disable aalib if the flag is not present, and specificly 
enable it if it is.  mplayer is a particularly nasty package, it has a great 
amount of dependencies and apparently aalib slipped through.

In case an ebuild is rather complex, a diff might be more appropriate as it 
makes clear where the changes are, but again it is a matter of personal 
judgement. (Also not all dev's are the same).

What must allways be present though is a comment on why the made changes are 
made, and what the possible repercussions could be (if any).

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] common ebuild mistakes

[Aron Griffis]

Martin, Stephen wrote:	[Fri May 23 2003, 03:15:33PM EDT]
> I've a couple of questions about this.  Last night I emerged mplayer and 
> noticed that aalib didn't get installed even though I had it in USE. 
> Obviously, fixing this is a trivial change to the RDEPEND section of the 
> ebuild (aalib is autodetected by mplayer and so no change to $myconf is 
> necessary).  

Two comments here:

1. It should be in both DEPEND and RDEPEND, since aalib is required at
   both compile-time and run-time.

2. Changing $myconf is necessary.  The presence of aalib on the system
   should not determine whether mplayer uses aalib.  That should be
   determined by the USE flag.  In other words, mplayer should not use
   aalib when USE=-aalib, even if aalib exists on the system.

Portage provides a couple nice shortcuts to make #2 easier.  Those are
"use_enable" and "use_with".  For example (from vim.eclass)

   myconf="--with-features=huge \
   	--enable-cscope \
   	--enable-multibyte"
   myconf="${myconf} `use_enable gpm`"
   myconf="${myconf} `use_enable perl perlinterp`"
   myconf="${myconf} `use_enable python pythoninterp`"
   myconf="${myconf} `use_enable ruby rubyinterp`"

> What's the best way to handle small changes like this? 
> Should I just file a bug and state what needs to be done, or should I 
> file a bug and attach a diff?  Is there a rule of thumb for how large a 
> change has to be in order to warrant a diff or ebuild?

If you always attach a diff, then there's no room for misinterpretation
of your instructions.  I'd suggest always attaching a diff except for a
pure version bump.

Aron

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] common ebuild mistakes

[Martin, Stephen]

Aron Griffis wrote:
> 
> 2. Changing $myconf is necessary.  The presence of aalib on the system
>    should not determine whether mplayer uses aalib.  That should be
>    determined by the USE flag.  In other words, mplayer should not use
>    aalib when USE=-aalib, even if aalib exists on the system.
> 

Thanks for the good advice.  I did think of this myself, however mplayer 
doesn't seem to recognize a --disable-aa flag.  I tried it with aalib 
installed and I still got aalib support.  What I probably should have 
said in my original post was that editing $myconf wouldn't work, not 
that it wasn't necessary.  I'm not sure if there's a way around this, 
perhaps the Makefile needs to be patched?

-- 
Stephen C. Martin

PGP/GnuPG key 1024D/8C4FCA5D


--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] autoconf variables and USE (was: Re: [gentoo-dev] common ebuild mistakes)

[Stanislav Brabec]

Martin, Stephen wrotte:
> Aron Griffis wrote:
> > 
> > 2. Changing $myconf is necessary.  The presence of aalib on the system
> >    should not determine whether mplayer uses aalib.  That should be
> >    determined by the USE flag.  In other words, mplayer should not use
> >    aalib when USE=-aalib, even if aalib exists on the system.
> I'm not sure if there's a way around this, 
> perhaps the Makefile needs to be patched?

If configure option --disable does not exist, you can use very often
configure cache variables:

./configure ... -C

Now watch cache and add variable name to ebuild script.

For example see /usr/portage/app-emulation/wine/wine-20030508.ebuild

(blocking jack is done by this way)

-- 
Stanislav Brabec
http://www.penguin.cz/~utx

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] common ebuild mistakes

[Edward Duffy]

On the one ebuild I've sumbitted, the dev that committed it added a line
for
DEPEND="virtual/glibc"

What wouldn't depend on glibc, isn't that a given?  A quick scan
through the portage directory turns up:
# find /usr/portage/ -iname '*.ebuild' | xargs grep "virtual/glibc" 
   | wc -l
   1982
# find /usr/portage/ -iname '*.ebuild' | xargs grep -v "virtual/glibc" 
   | wc -l
406821

So most ebuilds don't do this anyway.  What's the rule of thumb for
adding this as a dep?

On Thu, 2003-05-22 at 21:30, Alastair Tse wrote:
> Hi,
> 
> I've written up a list of common mistakes that users make when
> submitting ebuilds to us for inclusion. This stems from the discussion
> earlier on the list about the quality of user-submitted ebuilds.



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] common ebuild mistakes

[Georgi Georgiev]

On 26/05/2003 at 13:18:44(-0400), Edward Duffy used 0.8Kbytes just to say:
> On the one ebuild I've sumbitted, the dev that committed it added a line
> for
> DEPEND="virtual/glibc"
> 
> What wouldn't depend on glibc, isn't that a given?  A quick scan
> through the portage directory turns up:
> # find /usr/portage/ -iname '*.ebuild' | xargs grep "virtual/glibc" 
>    | wc -l
>    1982
> # find /usr/portage/ -iname '*.ebuild' | xargs grep -v "virtual/glibc" 
>    | wc -l
> 406821

This gives you the number of LINES that do not have virtual/glibc, not the
files that don't. You'd want something like:

# find /usr/portage -iname '*.ebuild' | xargs -i sh -c 'grep -q "virtual/glibc" {} || echo {}'

However, since you already have the number of packages that DO have the line -
you only need to substract it from the total number of ebuilds.

# find /usr/portage -iname '*.ebuild' | wc -l
   8587

-- 
 /^^^^^^^^^^^^^^^^^^^^^^^^^^^\/^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\
/ Georgi Georgiev    (-<     / Support your local police force  \
\ chutz@chubaka.net  /\   .o)\ -- steal!!                       /
/ +81(90)6266-1163  V_/_ |(/)/                                  \
\___________________________/\__________________________________/

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] common ebuild mistakes

[Edward Duffy]

d'oh! I feel stupid.  So it's about 20-25% of the ebuild that use that
depend on it...still seems kind of low.

On Mon, 2003-05-26 at 14:12, Georgi Georgiev wrote:
> On 26/05/2003 at 13:18:44(-0400), Edward Duffy used 0.8Kbytes just to say:
> > On the one ebuild I've sumbitted, the dev that committed it added a line
> > for
> > DEPEND="virtual/glibc"
> > 
> > What wouldn't depend on glibc, isn't that a given?  A quick scan
> > through the portage directory turns up:
> > # find /usr/portage/ -iname '*.ebuild' | xargs grep "virtual/glibc" 
> >    | wc -l
> >    1982
> > # find /usr/portage/ -iname '*.ebuild' | xargs grep -v "virtual/glibc" 
> >    | wc -l
> > 406821
> 
> This gives you the number of LINES that do not have virtual/glibc, not the
> files that don't. You'd want something like:
> 
> # find /usr/portage -iname '*.ebuild' | xargs -i sh -c 'grep -q "virtual/glibc" {} || echo {}'
> 
> However, since you already have the number of packages that DO have the line -
> you only need to substract it from the total number of ebuilds.
> 
> # find /usr/portage -iname '*.ebuild' | wc -l
>    8587


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] common ebuild mistakes

[George Shapovalov]

Ok, getting back to topic:
DEPEND is a required field in ebuild (RDEPEND  though may be omitted, in which 
case it is filled in from DEPEND). As such it makes sense to put some 
absolutely something basic in DEPEND for the package which does not have any 
apparent (as non-trivial, not bad-researched) dependencies. In that respect 
virtual/glibc perfectly fits the bill...

On the other hand I had to delete this line from some DEPEND's where some 
other stuff has been listed as well. In this case virtual/glibc does not add 
anything meaningfull and only increases size of ebuild.
As for number of packages that contain this "dependency": well it is quite 
common for packages to require some libs, etc. So majority of stuff in 
portage have non-empty DEPEND anyway..

George


On Monday 26 May 2003 11:20, Edward Duffy wrote:
> d'oh! I feel stupid.  So it's about 20-25% of the ebuild that use that
> depend on it...still seems kind of low.
>
> On Mon, 2003-05-26 at 14:12, Georgi Georgiev wrote:
> > On 26/05/2003 at 13:18:44(-0400), Edward Duffy used 0.8Kbytes just to say:
> > > On the one ebuild I've sumbitted, the dev that committed it added a
> > > line for
> > > DEPEND="virtual/glibc"
> > >
> > > What wouldn't depend on glibc, isn't that a given?  A quick scan



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] common ebuild mistakes

[Dylan Carlson]

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

On Mon May 26 2003 2:49 pm, George Shapovalov wrote:
> Ok, getting back to topic:
> DEPEND is a required field in ebuild (RDEPEND  though may be omitted, in
> which case it is filled in from DEPEND). As such it makes sense to put
> some absolutely something basic in DEPEND for the package which does not
> have any apparent (as non-trivial, not bad-researched) dependencies. In
> that respect virtual/glibc perfectly fits the bill...

The fact that this virtual was named "glibc" from the beginning was 
probably a mistake.   It should have been named "libc".

It is conceivable, if not desireable, that we may have more than one libc 
available to users -- alternatives to glibc.  Whether that's newlib, or a 
*BSD libc, or some other libc ... others exist and just haven't been 
integrated into the tree yet.

Even though I _eventually_ anticipate "virtual/glibc" being changed to 
"virtual/libc" -- I can't see this virtual being particularly useful from 
an ebuild perspective.  Instead we would see new USE flags for each 
different libc to handle compatibility issues.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Developer, Java Lead -- Gentoo Linux
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+0mWGPQS8wXCOFl8RAsIaAJ4pBRuS8z8qljtqAiAJKY4Ke032vwCfdkJ/
MlKDQXMwSJEuxEHXVcu90O4=
=0tYF
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] common ebuild mistakes

[Aron Griffis]

George Shapovalov wrote:[Mon May 26 2003, 02:49:36PM EDT]
> As such it makes sense to put some absolutely something basic in
> DEPEND for the package which does not have any apparent (as
> non-trivial, not bad-researched) dependencies. In that respect
> virtual/glibc perfectly fits the bill...

DEPEND="" works just as well.  Since glibc is in the default profile,
there's no reason to list it as a dependency, just like we can assume
some basic shell utilities are present when the ebuild is processed.

Aron

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] common ebuild mistakes

[Zach Welch]

Aron Griffis wrote:
 > George Shapovalov wrote:[Mon May 26 2003, 02:49:36PM EDT]
 >
 >> As such it makes sense to put some absolutely something basic in
 >> DEPEND for the package which does not have any apparent (as
 >> non-trivial, not bad-researched) dependencies. In that respect
 >> virtual/glibc perfectly fits the bill...
 >
 >
 > DEPEND="" works just as well.  Since glibc is in the default profile,
 >  there's no reason to list it as a dependency, just like we can
 > assume some basic shell utilities are present when the ebuild is
 > processed.
 >

Depending on the degree you are talking here, I tend to disagree with
the notion of not including some so call "basic" dependencies, because
profiles can have variations that may include stripping out some core
components.  As we move into the embedded realm, the definition of our
"core profile" will need to be reduced, so adding full dependency
information now is not necessarily a bad thing.

Instead, we need to clarify a truly minimal system set of packages (such
as libc) for which their dependency information need not be included.
This will probably be taken up as part of the embedded project's efforts
to scale the system down, so there is not pressure to do this now.

The tools already exists to build a dependecy list by tracking what the
actual build process uses during execution, and I have seen a couple of
ebuilds in the tree that seem to have used them.  This may not be a bad
standard practice to follow if those few core packages can be put on a
'whitelist' for exclusion by those tools.  At some distant point,
automating this process with a tool would not be a bad thing:

emerge --makedeps package-1.0.ebuild

This would build the package, tracking the deps, and modifying the
ebuild to update the build dependencies.  The recent thread that talked
about collecting branch prediction information by automatically running
the program a few times suggests to me that a similar process could be
applied to also detect RDEPENDS.  The above flag should also imply the
use of --digest run as a finalization step.

Cheers,

Zach Welch
Gentoo Embedded Lead
Superlucidity Services



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] common ebuild mistakes

[William McArthur]

I'd like to add to the list-all-deps-including-packages-in-system
because long ago I wanted to install sys-apps/man before I had installed
the full system so that I could read man pages before I started my full
install. The problem was man requires a pager like less to work.

You can read the bug report here: 
http://bugs.gentoo.org/show_bug.cgi?id=6565

The end result was: man and less are both in system so that one does not 
  need to depend on the other as they will both be installed. I'm of the 
opinion this is the wrong choice but whatever, life goes on, I worked 
around the problem.

Sandy

Zach Welch wrote:
> Aron Griffis wrote:
>> George Shapovalov wrote:[Mon May 26 2003, 02:49:36PM EDT]
>> 
>>> As such it makes sense to put some absolutely something basic in 
>>> DEPEND for the package which does not have any apparent (as 
>>> non-trivial, not bad-researched) dependencies. In that respect 
>>> virtual/glibc perfectly fits the bill...
>> 
>> DEPEND="" works just as well.  Since glibc is in the default
>> profile, there's no reason to list it as a dependency, just like we
>> can assume some basic shell utilities are present when the ebuild
>> is processed.
>> 
> 
> Depending on the degree you are talking here, I tend to disagree with
> the notion of not including some so call "basic" dependencies,
> because profiles can have variations that may include stripping out
> some core components.  As we move into the embedded realm, the
> definition of our "core profile" will need to be reduced, so adding
> full dependency information now is not necessarily a bad thing.
> 
> Instead, we need to clarify a truly minimal system set of packages
> (such as libc) for which their dependency information need not be
> included. This will probably be taken up as part of the embedded
> project's efforts to scale the system down, so there is not pressure
> to do this now.


--
gentoo-dev@gentoo.org mailing list