[gentoo-dev] Very bad ebuild-writing practice.

[gentoo-dev] Very bad ebuild-writing practice.

[Dan Naumov]

I've just found something that I personally consider very bad ebuild-writing practice and filled a bug-report about it at: http://bugs.gentoo.org/show_bug.cgi?id=6642 I also think, it's worth pointing out to some who don't visit BugZilla, as I consider the issue to be rather important:

=================================
app-games/quakeforge/quakeforge-0.5.0.ebuild claims to provide the users with a 0.5.0 release. The 0.5.0 release does NOT even exist. The only thing that exists is a 0.5 development branch, from which, a 0.5.0 release will be eventually made.

SRC_URI="http://www.quakeforge.org/files/quakeforge-current.tar.bz2" points to a CVS snapshot that's autogenerated every hour without going through any kind of QA. Since when do we allow ebuilds to point at hourly CVS snapshots of a development tree of a program that is undergoing heavy changes ?! If you emerge quakeforge using that ebuild, it might refuse to compile because the tree is broken at that very moment. It might compile, but the compile options have changed making the ebuild somewhat obsolete. And even if it compiles, it *WILL* break, because it's expected of it, it's a development tree.

Bad. Bad. Bad.
=================================

Sincerely,
Dan Naumov aka Jago

Re: [gentoo-dev] Very bad ebuild-writing practice.

[Jeremiah Mahler]

On Sat, Aug 17, 2002 at 07:09:05PM +0300, Dan Naumov wrote:
> I've just found something that I personally consider very bad ebuild-writing practice and filled a bug-report about it at: http://bugs.gentoo.org/show_bug.cgi?id=6642 I also think, it's worth pointing out to some who don't visit BugZilla, as I consider the issue to be rather important:
> 
> =================================
> app-games/quakeforge/quakeforge-0.5.0.ebuild claims to provide the users with a 0.5.0 release. The 0.5.0 release does NOT even exist. The only thing that exists is a 0.5 development branch, from which, a 0.5.0 release will be eventually made.
> 
> SRC_URI="http://www.quakeforge.org/files/quakeforge-current.tar.bz2" points to a CVS snapshot that's autogenerated every hour without going through any kind of QA. Since when do we allow ebuilds to point at hourly CVS snapshots of a development tree of a program that is undergoing heavy changes ?! If you emerge quakeforge using that ebuild, it might refuse to compile because the tree is broken at that very moment. It might compile, but the compile options have changed making the ebuild somewhat obsolete. And even if it compiles, it *WILL* break, because it's expected of it, it's a development tree.
> 
> Bad. Bad. Bad.
> =================================
> 
> Sincerely,
> Dan Naumov aka Jago
> 

I understand how the case above is misleading in that most people
expect a relatively stable release using that naming convention.

But suppose someone did want an ebuild for the hourly CVS snapshots?
How should it be named?

quakeforge-0.5.0.ebuild             # works, but is misleading
quakeforge-0.5.0-cvs.ebuild         # ERR!
quakeforge-0.5.0_cvs.ebuild         # ERR!
quakeforge-0.5.0_cvs_hourly.ebuild	# ERR!
quakeforge-0.5.0_beta1.ebuild	    # OK, but misleading also
???

I have made a few ebuilds and one thing that frustrates me is
the very particular ebuild naming requirements. In fact, I have
an ebuild pending in which I had to use a version number of
zero even though there is no version yet in order to get it to
work.

http://bugs.gentoo.org/show_bug.cgi?id=6209

-- 
Jeremiah Mahler
<jmahler@pacbell.net>

Re: [gentoo-dev] Very bad ebuild-writing practice.

[Dan Naumov]

On Sat, 17 Aug 2002 09:30:37 -0700
Jeremiah Mahler <jmahler@pacbell.net> wrote:

> But suppose someone did want an ebuild for the hourly CVS snapshots?
> How should it be named?

My personal belief is that ebuilds of hourly CVS snapshots should never leave the PORTDIR_OVERLAY of the original author. IMHO, Gentoo Portage is no place for autogenerated, untested CVS stuff. How are you going to go around non-compiling snapshots of broken trees and new compile options that appear from time to timw anyways ?

Ebuilds should be writted for things that are "set in stone" and don't go around changing on an hourly basis. You really don't want to have 2 users run "emerge blah" and get different versions of the same program, even though "emerge -u rsync" was run at the same time. This would be a horrible mess (which is currently the case with QuakeForge ebuild).

Sincerely,
Dan Naumov aka Jago

Re: [gentoo-dev] Very bad ebuild-writing practice.

[Bart Verwilst]

Ok, i have NO idea what this thread is about, i just glanced at this, and i'll 
give ya my suggestion, that's it :o)

|| But suppose someone did want an ebuild for the hourly CVS snapshots?
|| How should it be named?
||
|| quakeforge-0.5.0.ebuild             # works, but is misleading
|| quakeforge-0.5.0-cvs.ebuild         # ERR!
|| quakeforge-0.5.0_cvs.ebuild         # ERR!
|| quakeforge-0.5.0_cvs_hourly.ebuild	# ERR!
|| quakeforge-0.5.0_beta1.ebuild	    # OK, but misleading also
|| ???
||

quakeforge-0.5.0_pre020817.ebuild

:o)

See ya

-- 
Bart Verwilst
Gentoo Linux Developer, Release Coordinator
Gent, Belgium

Re: [gentoo-dev] Very bad ebuild-writing practice.

[Dan Naumov]

On Sat, 17 Aug 2002 18:50:26 +0200
Bart Verwilst <verwilst@gentoo.org> wrote:

> quakeforge-0.5.0_pre020817.ebuild

That won't work with hourly auto-generated snapshots in the case where older snapshots are no longer kept on the server, just like our quakeforge case. This would require hourly auto-generated ebuilds and the borkage I mentioned in my previous mails would still exist :|

Dan Naumov aka Jago

Re: [gentoo-dev] Very bad ebuild-writing practice.

[mike]

this was a known issue when the ebuild made (i made it ;])
but the solution was to grab a stable-ish build, make the digest
off of it, and post it to ibiblio.  then, when the next stable-ish
version came along, a new digest would be put out and the
version be bumped up to -r1 and so on and so forth.  the
problem lays with the fact that the last release of quakeforge
is like 0.3.0.  this version is dead and majorly obsolete.
the 'newer' versions get put out when someone famil with
the project feels it is needed.  also, that tar ball isnt auto-generated
every single hour ... not sure if it is even autogenerated ...
but yeah, i think the version should have had at least a
date tag on it now that you mention it.  once i fix the
ebuild for gcc3.x ill post the new one with a date tag
-mike

----- Original Message -----
From: "Dan Naumov" <jago@telefragged.com>
To: <gentoo-dev@gentoo.org>
Sent: Saturday, August 17, 2002 13:03
Subject: Re: [gentoo-dev] Very bad ebuild-writing practice.


> On Sat, 17 Aug 2002 18:50:26 +0200
> Bart Verwilst <verwilst@gentoo.org> wrote:
>
> > quakeforge-0.5.0_pre020817.ebuild
>
> That won't work with hourly auto-generated snapshots in the case where
older snapshots are no longer kept on the server, just like our quakeforge
case. This would require hourly auto-generated ebuilds and the borkage I
mentioned in my previous mails would still exist :|
>
> Dan Naumov aka Jago
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
>

Re: [gentoo-dev] Very bad ebuild-writing practice.

[Dan Naumov]

On Sat, 17 Aug 2002 14:12:54 -0400
"mike" <vapier@netzero.com> wrote:

> this was a known issue when the ebuild made (i made it ;])
> but the solution was to grab a stable-ish build, make the digest
> off of it, and post it to ibiblio.  then, when the next stable-ish
> version came along, a new digest would be put out and the
> version be bumped up to -r1 and so on and so forth.  the
> problem lays with the fact that the last release of quakeforge
> is like 0.3.0.  this version is dead and majorly obsolete.
> the 'newer' versions get put out when someone famil with
> the project feels it is needed.  also, that tar ball isnt auto-generated
> every single hour ... not sure if it is even autogenerated ...
> but yeah, i think the version should have had at least a
> date tag on it now that you mention it.  once i fix the
> ebuild for gcc3.x ill post the new one with a date tag
> -mike

The 0.5.x CVS snapshots to which the ebuild links ARE automatically generated every hour. Ask on OPN #QuakeForge if you don't trust me.

Dan Naumov aka Jago

Re: [gentoo-dev] Very bad ebuild-writing practice.

[Blake Watters]

Wouldn't it seem most reasonable for the ebuild author to create 
snapshots, test them, and have those snapshots merged into Portage? Then 
the package can be repackaged at a later date, tested again and released. 
This also allows you to use the date as the version number, bypassing any 
problems with the naming conventions.

I agree that hourly build releases should not make it into the portage 
tree unmasked. Perhaps masking such packages or creating an experimental 
organizational unit under portage for such packages to live would be 
advantageous.

Blake

 
On Sat, 17 Aug 2002, Dan Naumov wrote:

> On Sat, 17 Aug 2002 09:30:37 -0700
> Jeremiah Mahler <jmahler@pacbell.net> wrote:
> 
> > But suppose someone did want an ebuild for the hourly CVS snapshots?
> > How should it be named?
> 
> My personal belief is that ebuilds of hourly CVS snapshots should never leave the PORTDIR_OVERLAY of the original author. IMHO, Gentoo Portage is no place for autogenerated, untested CVS stuff. How are you going to go around non-compiling snapshots of broken trees and new compile options that appear from time to timw anyways ?
> 
> Ebuilds should be writted for things that are "set in stone" and don't go around changing on an hourly basis. You really don't want to have 2 users run "emerge blah" and get different versions of the same program, even though "emerge -u rsync" was run at the same time. This would be a horrible mess (which is currently the case with QuakeForge ebuild).
> 
> Sincerely,
> Dan Naumov aka Jago
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
> 

Re: [gentoo-dev] Very bad ebuild-writing practice.

[mike]

if it made it in unmasked but with a cvs date tag, would that
make it more agreeable ?
-mike

----- Original Message -----
From: "Blake Watters" <sbw@metalab.unc.edu>
To: "Dan Naumov" <jago@telefragged.com>
Cc: <gentoo-dev@gentoo.org>
Sent: Saturday, August 17, 2002 14:40
Subject: Re: [gentoo-dev] Very bad ebuild-writing practice.


> Wouldn't it seem most reasonable for the ebuild author to create
> snapshots, test them, and have those snapshots merged into Portage? Then
> the package can be repackaged at a later date, tested again and released.
> This also allows you to use the date as the version number, bypassing any
> problems with the naming conventions.
>
> I agree that hourly build releases should not make it into the portage
> tree unmasked. Perhaps masking such packages or creating an experimental
> organizational unit under portage for such packages to live would be
> advantageous.
>
> Blake
>
>
> On Sat, 17 Aug 2002, Dan Naumov wrote:
>
> > On Sat, 17 Aug 2002 09:30:37 -0700
> > Jeremiah Mahler <jmahler@pacbell.net> wrote:
> >
> > > But suppose someone did want an ebuild for the hourly CVS snapshots?
> > > How should it be named?
> >
> > My personal belief is that ebuilds of hourly CVS snapshots should never
leave the PORTDIR_OVERLAY of the original author. IMHO, Gentoo Portage is no
place for autogenerated, untested CVS stuff. How are you going to go around
non-compiling snapshots of broken trees and new compile options that appear
from time to timw anyways ?
> >
> > Ebuilds should be writted for things that are "set in stone" and don't
go around changing on an hourly basis. You really don't want to have 2 users
run "emerge blah" and get different versions of the same program, even
though "emerge -u rsync" was run at the same time. This would be a horrible
mess (which is currently the case with QuakeForge ebuild).
> >
> > Sincerely,
> > Dan Naumov aka Jago
> > _______________________________________________
> > gentoo-dev mailing list
> > gentoo-dev@gentoo.org
> > http://lists.gentoo.org/mailman/listinfo/gentoo-dev
> >
>
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
>

Re: [gentoo-dev] Very bad ebuild-writing practice.

[Jose Alberto Suarez Lopez]

Hi,

Really we the ebuild try first dowload a version from ibliblio mirror of
gentoo, where is a snapshot and it works and build without problems.
If the ebuild download the version from the original quakeforge url can be an
aislated error for faild connection or similar.

regards

José Alberto Suárez López
-- 
<bass@gentoo.org> (JabberID)
<bass@adala.org>
<josealberto.suarez@hispalinux.es>
http://www.gentoo.org
http://www.adala.org
http://bass.dnsalias.com
http://gimp.es.gnome.org

Re: [gentoo-dev] Very bad ebuild-writing practice.

[Alexander Gretencord]

Dan Naumov wrote:
>>But suppose someone did want an ebuild for the hourly CVS snapshots?
>>How should it be named?
> 
> My personal belief is that ebuilds of hourly CVS snapshots should
> never leave the PORTDIR_OVERLAY of the original author. IMHO, 
 > Gentoo Portage is no place for autogenerated, untested CVS stuff.
 > How are you going to go around non-compiling snapshots of broken
 > trees and new compile options that appear from time to timw
 > anyways ?

Well I think we do need such ebuilds _but_ they gotta be named 
accordingly. You have to see that it is a cvs ebuild. I for one use 
mplayer as my multimedia player of choice but I won't use the ebuild 
because mplayer releases don't come too often. For a very long time 
there was just the 0.60 release of mplayer which sucked, while cvs 
always builds (just personal exp tho) and has tons of features. I have 
not bothered to look at the cvs eclass and build my mplayer myself but 
mplayer is such an example where a cvs ebuild would be great. Another 
example is is kde. Why not use the convenience of portage to test the 
latest kde.

Alex

Re: [gentoo-dev] Very bad ebuild-writing practice.

[Charles Lacour]

On Saturday 17 August 2002 11:50, Bart Verwilst wrote:
> Ok, i have NO idea what this thread is about, i just glanced at this, and
> i'll give ya my suggestion, that's it :o)
>
> || But suppose someone did want an ebuild for the hourly CVS snapshots?
> || How should it be named?
> ||
> || quakeforge-0.5.0.ebuild             # works, but is misleading
> || quakeforge-0.5.0-cvs.ebuild         # ERR!
> || quakeforge-0.5.0_cvs.ebuild         # ERR!
> || quakeforge-0.5.0_cvs_hourly.ebuild	# ERR!
> || quakeforge-0.5.0_beta1.ebuild	    # OK, but misleading also
> || ???
>
> quakeforge-0.5.0_pre020817.ebuild
>

I agree with Dan that an ebuild package that consists of an hourly CVS 
snapshot, or a direct CVS read is inappropriate for the main Gentoo tree.

I disagree with what he said about "Ebuilds should be written for things that 
are "set in stone" and don't go around changing on an hourly basis."

An ebuild (and portage in general) is a packaging and installation/removal 
system. Saying that it shouldn't be used for short-lived releases is like 
saying you shouldn't use RPMs or tarballs for such things.

I know Daniel Robbins is (or was at last report, about two weeks ago) 
dedicated to having just one "Gentoo", that has everything in the world in 
it, and that problems like flaky packages are handled by "quality control" 
(his words).

I personally think he's fantasizing on this issue. While it's quite possible 
to exert that type of quality control and have a stable, dependable set of 
packages (call it a "release" for brevity), I don't belive it's possible to 
have - in the same time and place - the rapid development and 
up-to-the-minute package selection which has so far characterized Gentoo. 
(And from what I've seen, it has characterized Gentoo because the developers 
want it that way.)

I'd suggest another location that ebuilds for packages of less-than-sterling 
character could go. Once they're done going through the development, alpha 
testing and rough beta testing, then they'd be candidates for masked ebuilds 
for the main community to check out.

As far as the name for cvs ebuilds goes, I think Bart had a very elegant 
solution for doing it within the current system. I'd rather see something 
like:
quakeforge-0.5.0-cvs-20020820201013.ebuild, where the code that pulls the CVS 
entry in picks apart the time and pulls the cvs tree as of that point in 
time.  (If you asked for quakeforge-0.5.0-cvs.ebuild, it would translate it 
to be as if you had typed "quakeforge-0.5.0-cvs-$(date 
+%Y%m%d%H%M%S).ebuild".)

Re: [gentoo-dev] Very bad ebuild-writing practice.

[Troy Dack]

On Mon, 2002-08-19 at 01:44, Alexander Gretencord wrote:
> Dan Naumov wrote:
> >>But suppose someone did want an ebuild for the hourly CVS snapshots?
> >>How should it be named?
> > 
> > My personal belief is that ebuilds of hourly CVS snapshots should
> > never leave the PORTDIR_OVERLAY of the original author. IMHO, 
>  > Gentoo Portage is no place for autogenerated, untested CVS stuff.
>  > How are you going to go around non-compiling snapshots of broken
>  > trees and new compile options that appear from time to timw
>  > anyways ?
> 
> Well I think we do need such ebuilds _but_ they gotta be named 
> accordingly. You have to see that it is a cvs ebuild. I for one use 
> mplayer as my multimedia player of choice but I won't use the ebuild 
> because mplayer releases don't come too often. For a very long time 
> there was just the 0.60 release of mplayer which sucked, while cvs 
> always builds (just personal exp tho) and has tons of features. I have 
> not bothered to look at the cvs eclass and build my mplayer myself but 
> mplayer is such an example where a cvs ebuild would be great. Another 
> example is is kde. Why not use the convenience of portage to test the 
> latest kde.
> 
> Alex

Have a look at Dan's kde-cvs ebuilds @
http://www.gentoo.org/~danarmak/kde-cvs.html

I've been using them for the last couple of months with no major
problems.  I don't think it would be too difficult to adapt them for
mplayer or any other application.

I think that using cvs eclass based ebuilds instead of a snapshot tar
ball is preferably, at least the end user is clear on the type of code
that they are going to be receiving and attempting to compile.

-- 
	Troy Dack
	http://linuxserver.tkdack.com		http://gentoo.tkdack.com

[gentoo-dev] Re: Very bad ebuild-writing practice.

[Paul]

Troy Dack <troy@tkdack.com>, on Mon Aug 19, 2002 [02:40:59 PM] said:
> On Mon, 2002-08-19 at 01:44, Alexander Gretencord wrote:
[...]
> > 
> > Well I think we do need such ebuilds _but_ they gotta be named 
> > accordingly. You have to see that it is a cvs ebuild. I for one use 
[...]
> 
> Have a look at Dan's kde-cvs ebuilds @
> http://www.gentoo.org/~danarmak/kde-cvs.html
> 
> I've been using them for the last couple of months with no major
> problems.  I don't think it would be too difficult to adapt them for
> mplayer or any other application.
> 
> I think that using cvs eclass based ebuilds instead of a snapshot tar
> ball is preferably, at least the end user is clear on the type of code
> that they are going to be receiving and attempting to compile.
> 
> -- 
> 	Troy Dack

	Hi;

	I agree that cvs ebuilds are useful, as long as they
are named properly. Dont take away functionality from me, just
because I might shoot myself in the foot.
	Can something like this be done for the app-doc/howto-*
ebuilds?  The source these things come from seems to be generated
daily, and the frozen snapshot we have tends to be months old...
The latest is available for free, we should take advantage of it.

Paul
set@pobox.com

Re: [gentoo-dev] Very bad ebuild-writing practice.

[Paul de Vrieze]

On Monday 19 August 2002 03:13, Charles Lacour wrote:
> As far as the name for cvs ebuilds goes, I think Bart had a very elegant
> solution for doing it within the current system. I'd rather see something
> like:
> quakeforge-0.5.0-cvs-20020820201013.ebuild, where the code that pulls the
> CVS entry in picks apart the time and pulls the cvs tree as of that point
> in time.  (If you asked for quakeforge-0.5.0-cvs.ebuild, it would translate
> it to be as if you had typed "quakeforge-0.5.0-cvs-$(date
> +%Y%m%d%H%M%S).ebuild".)
>

Take it a step further and put only -cvs.ebuild files in the portage tree, and 
put in the package repository the ebuild files as proposed. Further cvs 
ebuilds shouldn't be part of a world update when their normal version number 
hasn't changed. (Version numbers should change to reflect the latest 
"official" version number of the package). A possible cvsupdate option might 
check for packages that have not been merged for a certain number of days.

For cvs snapshots I believe the current procedure where a snapshot is put on 
the gentoo mirrors (as SRC_URI) is best. 

Paul

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