Re: [gentoo-dev] Community driven meta distribution or only distribution (was Re: Several portage trees)

[Susie]

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

On Tue, 29 Apr 2003 11:17:13 -0700
"Robin H.Johnson" <robbat2@g.o> wrote:


> lintool/repoman do remind you that some of those are required, but for
> the most part they require a human to check. The original ebuild

I've found lintool useful.  Though it does complain sometimes if you
omit a tag as it wont be used or if you comment it out.  RDEPEND I think
is one it made some complaint on so admittedly I forgot to re comment it
out on my template I use so I have to go check later and make sure all
my older ebuilds again comment it out.

> looked as if it was written using only the guide, and none of the
> existing ebuilds in portage, many of which server as excellent
> examples of ebuild style and how things are done.

My first ebuild or two was only using the guide or peaking at some
existing ebuilds.  Then I found "man 5 ebuild" alot more useful as it
listed more things I seemed to need to use.  But I was unaware that that
particular man page existed til someone pointed it out to me.

> However you are partially correct that some of this should be added to
> [1].
> most importantly,
> - say required items SLOT/KEYWORDS/IUSE/HOMEPAGE
> - say that all documentation should be installed

Yes that doccumention comment is important.  For example I had no clue
what should be added that way at first.  Til again someone pointed it
out.  I was unsure if the "README" etc that comes with a tar should be
in there.   As for the slots I understand their usage however I'm unsure
as to if new ebuilds that have no priors for that software if they need
a slot number or should just stay at "0".  Personally I've left them at
"0" as I've seen no other ebuild for them.  I get the keyword use good
enough for the homepages tho some things don't have them and I've had to
resort to using source forge project page or freshmeat info page.

> - recommend econf/emake/einstall instead of normal variants
> - patch+src_unpack is not efficent and maybe incorrect, use
> PATCHES="..."

I do like the comments in the skel ebuild for pointing out that emake
and einstall don't work for everything.  I've had builds fail and found
out that I just had to switch that then they were fine.  As for the
patch yes I have no clue how to do that so that has stopped me from
trying to make the odd thing.  Also I'm unsure as to how to make an
ebuild fetch secondary packages other than listing them as depends and
then writing ebuilds for those items.  I'd like to make an ebuild for a
ham radio quiz program for those wanting to write their license but for
example if I do it requires I fetch a group of text files from the arrl
site.  The perl script that generates the quizes needs those texts to
make the questions.  I grasp how to make the ebuild for the perl script
for the most part but not how to make that ebuild grab those files and
shift them to where it's needed.  I'm guessing I'd have to put a symlink
in the /usr/bin for the script and have the script and the text files in
a /usr/share/<dir>

> Some of the things I mentioned are also partially my personal
> preferences to make life easier on myself. People's code says a lot
> about them generally, and if your submitted ebuilds look sloppy and
> that lessens the chance that developers will even go thru them and
> say what is wrong, let along clean them up.

Yes but one point is a person wouldn't have a clue if it's sloppy or not
if someone doesn't say why and make a suggestion.  Though I've found so
far people have nicely done that for me.  They've not been nasty and put
me off making ebuilds frankly they were reasonably encouraging and just
pointed out things I'd missed.  Which I felt bad about some were
probably dumb errors at the time but we all have lives outside our boxes
and sometimes that gets in the way for a moment or two.(I myself have a
special needs child to take care of, am busy with divorce stuff, about
to have surgery in about a month, and dealing with a variety of other
things... so occasionally I miss things.  I do know people have quite
the work load and are doing it voluntarily here so I do honestly feel
bad if I've needlessly added to that.  But usually I get told it once or
twice... I've taken the hint..)
 

> Repoman replaced lintool. I don't unfortunetly know of a tool that
> users can use to check ebuilds themselves, as repoman requires a CVS
> checkout. I have said previously that lintool needs to come back
> myself, and I have submitted some fixes for it to bugzilla myself.
> That document [2] does appear to contradict itself.

lintool is still there.  I know as I use it.  But it does complain on
odd things it probably shouldn't.  Not sure the full spectrum of what it
will complain about but on "lintool ebuild <path to ebuild>" I've had it
complain about tags that wont be used that I've either commented out or
just not put in.  But now I've learned it does that and I've got just
enough experience that most ebuilds are straight forward and if it fails
when I'm using it I check it further with lintool or start asking
questions.
 
> I personally try to avoid packages that do not fill at least one of
> the following requirements:
> 1) is actively maintained
> 2) is widely used
> 3) not directly useful to myself

I think that is a given for most people.  Except in my case if it looks
intresting/that it might be useful in the long run(even if it's not
personally useful to me) I may give it a try and check it out on gentoo
stable to help pass on stability, etc info to help it maybe get bumped
into portage.  
 
- -- 

Susie
arienadean@××××.ca
http://arienadean.tripod.com/

Digitally signed
GPG Key ID: E93F0D23
Key fingerprint = 33F8 0E9D 3AD1 23E0 C70F  ECC6 7871 D811 E93F 0D23

- -----------------------------------------------------------------------

"Science is everything we understand well enough to explain to a
computer. Art is everything else." - David Knuth 



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

iD8DBQE+ruqIeHHYEek/DSMRAicIAKCTEbm5bM2IZnf1JpHajWHAkV+E9wCfUIHt
z958tQXCSA33RXKWWYToD3s=
=rshx
-----END PGP SIGNATURE-----

--
gentoo-dev@g.o mailing list