[gentoo-dev] Do not modify ebuilds which are already in the tree... even if masked

[gentoo-dev] Do not modify ebuilds which are already in the tree... even if masked

[cilly]

Hi all,

I think it is worth to discuss about `Do not modify ebuilds which are  
already in the tree... even if masked.`

Sometimes ebuilds which are already in the portage tree are modified  
without changing the
version-number, i.e. ebuild-r1 is in the portage tree and the ebuild- 
r1 gets changed,
i.e. useflag or other issues without changing the version number to  
ebuild-r2. This causes
confusion i.e. in bug-reports.

My opinion is not to change any ebuild which is in the portage tree,  
even if the ebuild is masked.
I think the better way is to add an ebuild with an updated version  
number, even if the ebuild is still
masked.

I also recommend to manage hard-masked packages the same way, it  
prevents confusion in
bug-reports.

What do you think?

Cheers,

Cecilia
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Do not modify ebuilds which are already in the tree... even if masked

[Fernando J. Pereda]

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

On Tue, Jun 12, 2007 at 12:07:11PM +0200, cilly wrote:
>  Hi all,
> 
>  I think it is worth to discuss about `Do not modify ebuilds which are
>  already in the tree... even if masked.`
> 
>  Sometimes ebuilds which are already in the portage tree are modified
>  without changing the version-number, i.e. ebuild-r1 is in the portage
>  tree and the ebuild-r1 gets changed, i.e. useflag or other issues
>  without changing the version number to ebuild-r2. This causes
>  confusion i.e. in bug-reports.
> 
>  My opinion is not to change any ebuild which is in the portage tree,
>  even if the ebuild is masked.  I think the better way is to add an
>  ebuild with an updated version number, even if the ebuild is still
>  masked.
> 
>  I also recommend to manage hard-masked packages the same way, it
>  prevents confusion in bug-reports.
> 
>  What do you think?

I think this is also a bad idea. I seem to recall that this is
documented somewhere in the Developer Handbook...

- ferdy

-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

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

Re: [gentoo-dev] Do not modify ebuilds which are already in the tree... even if masked

[Petteri Räty]

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

cilly kirjoitti:
> Hi all,
> 
> I think it is worth to discuss about `Do not modify ebuilds which are
> already in the tree... even if masked.`
> 
> Sometimes ebuilds which are already in the portage tree are modified
> without changing the
> version-number, i.e. ebuild-r1 is in the portage tree and the ebuild-r1
> gets changed,
> i.e. useflag or other issues without changing the version number to
> ebuild-r2. This causes
> confusion i.e. in bug-reports.

http://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html

This is the current policy. So far it has worked quite well for me at least.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] Do not modify ebuilds which are already in the tree... even if masked

[Luca Barbato]

cilly wrote:
> What do you think?

There is already a guideline about it it basically says :

"Every changes that just fix an issue for a certain deals of users (e.g.
 optional dep version bump, different use handling, anything that makes
the program not build just in that particular case BUT doesn't affect
ALL the users, that could be perfectly fine with that specific merged
program) could be made w/out bumping the revision"

Again the key is having developers knowing what's going on and acting
considering their actions, not some set of detailed rules.

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Do not modify ebuilds which are already in the tree... even if masked

[cilly]

On Jun 12, 2007, at 12:21 PM, Luca Barbato wrote:

> There is already a guideline about it it basically says :
>
> "Every changes that just fix an issue for a certain deals of users  
> (e.g.
>  optional dep version bump, different use handling, anything that  
> makes
> the program not build just in that particular case BUT doesn't affect
> ALL the users, that could be perfectly fine with that specific merged
> program) could be made w/out bumping the revision"
>
> Again the key is having developers knowing what's going on and acting
> considering their actions, not some set of detailed rules.

Yeah, in general I agree, for most of the packages this works like it  
should. But for some packages / cases sometimes bugs or additional  
fixes or other problems do exist. May be it could be done as an  
advisory, i.e. remind package maintainer to keep the latest stable  
ebuild around for a while before removal.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Do not modify ebuilds which are already in the tree... even if masked

[cilly]

On Jun 12, 2007, at 12:20 PM, Petteri Räty wrote:

> http://devmanual.gentoo.org/general-concepts/ebuild-revisions/ 
> index.html
>
> This is the current policy. So far it has worked quite well for me  
> at least.

Okay, does this include ~ packages? And what about hard masked ones?--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Do not modify ebuilds which are already in the tree... even if masked

[Marius Mauch]

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

On Tue, 12 Jun 2007 12:07:11 +0200
cilly <cilly@cilly.mine.nu> wrote:

> Hi all,
> 
> I think it is worth to discuss about `Do not modify ebuilds which
> are already in the tree... even if masked.`
> 
> Sometimes ebuilds which are already in the portage tree are modified  
> without changing the
> version-number, i.e. ebuild-r1 is in the portage tree and the ebuild- 
> r1 gets changed,
> i.e. useflag or other issues without changing the version number to  
> ebuild-r2. This causes
> confusion i.e. in bug-reports.
> 
> My opinion is not to change any ebuild which is in the portage tree,  
> even if the ebuild is masked.
> I think the better way is to add an ebuild with an updated version  
> number, even if the ebuild is still
> masked.
> 
> I also recommend to manage hard-masked packages the same way, it  
> prevents confusion in
> bug-reports.
> 
> What do you think?

Not realistic. Think about it:
- upstream location for a package changes, so old SRC_URI stops
working. If we don't update the existing ebuild people can't use it
anymore, if we bump it to a new revision existing users "have to"
perform a pointless update.
- a mistake in the ebuild prevents installation for 10% of the users,
but doesn't affect runtime behavior. SHould we bump it just for that
and "force" the other 90% of the users to perform a pointless update?
- also due to eclasses this is practically impossible, if an eclass is
changed all ebuilds inheriting it are implicitly changed as well,
you can't really restrict that to revbumps.

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: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Do not modify ebuilds which are already in the tree... even if masked

[cilly]

On Jun 12, 2007, at 12:55 PM, Marius Mauch wrote:

Hi Marius,

> Not realistic. Think about it:
> - upstream location for a package changes, so old SRC_URI stops
> working. If we don't update the existing ebuild people can't use it
> anymore, if we bump it to a new revision existing users "have to"
> perform a pointless update.

In that case I agree to keep the version number, but mostly some  
other stuff is changed too, i.e. dependencies and the version number  
is still kept the same.

> - a mistake in the ebuild prevents installation for 10% of the users,
> but doesn't affect runtime behavior. SHould we bump it just for that
> and "force" the other 90% of the users to perform a pointless update?

Yes. This is in general a good idea, any mistake in an ebuild should  
be corrected by increasing the version number. I am not aware what  
the guide-lines say, but it is my opinion to let others know: the  
ebuild was buggy, see changelog... bla bla bla

> - also due to eclasses this is practically impossible, if an eclass is
> changed all ebuilds inheriting it are implicitly changed as well,
> you can't really restrict that to revbumps.

Well, I am not very familiar with eclasses, may be somebody else can  
give a hint?

Chers,

Cecilia
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Do not modify ebuilds which are already in the tree... even if masked

[Vlastimil Babka]

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

cilly wrote:
> I also recommend to manage hard-masked packages the same way, it
> prevents confusion in
> bug-reports.

I don't agree for hard-masked packages. Sometimes they are hard-masked
because of being under development, and are changed several times until
unmasked (think about new KDE versions etc). Revbumping with each change
and then finally unmasking something like -r15 is nuissance and looks
weird. Users shouldn't be using p.masked packages and if they do, they
should really know what they are doing, especially when filling bugs for
such packages as there are no guarantees while in p.mask.
- --
Vlastimil Babka (Caster)
Gentoo/Java
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGboh4tbrAj05h3oQRAvv1AJ45RRl0kr1246ug5H1ZdSTZ5i5j5QCfaq25
xLWsB9Pqbb8kPXVSe4Co4NM=
=SSi6
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Do not modify ebuilds which are already in the tree... even if masked

[cilly]

On Jun 12, 2007, at 1:50 PM, Vlastimil Babka wrote:

> I don't agree for hard-masked packages. Sometimes they are hard-masked
> because of being under development, and are changed several times  
> until
> unmasked (think about new KDE versions etc). Revbumping with each  
> change
> and then finally unmasking something like -r15 is nuissance and looks
> weird. Users shouldn't be using p.masked packages and if they do, they
> should really know what they are doing, especially when filling  
> bugs for
> such packages as there are no guarantees while in p.mask.

Okay, I understand that. Just keep in mind, that order bugs to the  
ebuilds might be more difficult without changing the version number.  
And the guidelines say, if an ebuild is changed the version number  
i.e. -rx should be increased.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Do not modify ebuilds which are already in the tree... even if masked

[cilly]

On Jun 12, 2007, at 1:56 PM, Christian Faulhammer wrote:

> P.S.: I think you are fighting against windmills here.  Most devs are
> happy with the current policy, and even I see no urgent point from  
> your
> arguments.

yeah, I already figured out...
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Do not modify ebuilds which are already in the tree... even if masked

[cilly]

On Jun 12, 2007, at 1:56 PM, Christian Faulhammer wrote:

> P.S.: I think you are fighting against windmills here.  Most devs are
> happy with the current policy, and even I see no urgent point from  
> your
> arguments.

So this will require users to file a bugreport, but I for myself am  
burned out in filing bugreports related to ebuilds concerning this  
matter... I know what is to be done by myself: uncomfortably browsing  
the source and packing the older ebuild into overlay. I thought, my  
idea would make things easier for others or an average user. But if  
my idea isn't liked I can't do anything else.
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Do not modify ebuilds which are already in the tree... even if masked

[Christian Faulhammer]

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

cilly <cilly@cilly.mine.nu>:

> Okay, I understand that. Just keep in mind, that order bugs to the  
> ebuilds might be more difficult without changing the version number.  
> And the guidelines say, if an ebuild is changed the version number  
> i.e. -rx should be increased.

 You have the cvs diff abilites and we have a header that says which
CVS revision one is having.

V-Li

-- 
http://www.gentoo.org/
http://www.faulhammer.org/
http://www.gnupg.org/

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

Re: [gentoo-dev] Do not modify ebuilds which are already in the tree... even if masked

[cilly]

On Jun 12, 2007, at 1:56 PM, Christoph Mende wrote:

> It seems a bit that you didn't fully understand that case. That  
> package
> fails to install for 10% but works flawlessly for the other 90%. Those
> 10% will get the fix even without a version bump, the other 90% don't,
> but that's ok, they don't need it. A version bump would mean wasting
> the time to recompile it for those 90%. I agree that there should be a
> ChangeLog entry, but I think nearly all devs do that already :>

I did understand. But sometimes the mods could cause an error while  
reemerging for some of the 90%. We had that already.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Do not modify ebuilds which are already in the tree... even if masked

[cilly]

On Jun 12, 2007, at 2:05 PM, Christian Faulhammer wrote:

>  You have the cvs diff abilites and we have a header that says which
> CVS revision one is having.

Well, who are bugreporters? I'd say a lot of users report bugs who  
don't use CVS at all. And they even don't know about the different  
CVS-versions. Then a maintainer would have to ask for the CVS  
version... takes time, requires additional interaction which could be  
prevented, if the ebuild number is unique. 
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Do not modify ebuilds which are already in the tree... even if masked

[Luca Barbato]

cilly wrote:
> So this will require users to file a bugreport, but I for myself am
> burned out in filing bugreports related to ebuilds concerning this
> matter... I know what is to be done by myself: uncomfortably browsing
> the source and packing the older ebuild into overlay.

Another solution could be provide a nice script that does that for you...

lu - there isn't only a solution.

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Do not modify ebuilds which are already in the tree... even if masked

[Michael Cummings]

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

cilly wrote:
> On Jun 12, 2007, at 12:55 PM, Marius Mauch wrote:
>> - a mistake in the ebuild prevents installation for 10% of the users,
>> but doesn't affect runtime behavior. SHould we bump it just for that
>> and "force" the other 90% of the users to perform a pointless update?
> 
> Yes. This is in general a good idea, any mistake in an ebuild should be
> corrected by increasing the version number. I am not aware what the
> guide-lines say, but it is my opinion to let others know: the ebuild was
> buggy, see changelog... bla bla bla

BEARD! If an ebuild I maintain gets a fix so that it can now build for
mips (or arm, or any other vital, important, but realistically small,
small, small segment of the user community) where it didn't before, and
it doesn't affect the other users, i'm not bumping it. I fail to see the
point in bumping a package when the only change is
	use arm && doblah
what's the point?


- --

- -----o()o----------------------------------------------
Michael Cummings   |    #gentoo-dev, #gentoo-perl
Gentoo Perl Dev    |    on irc.freenode.net
Gentoo/SPARC
Gentoo/AMD64
GPG: 0543 6FA3 5F82 3A76 3BF7  8323 AB5C ED4E 9E7F 4E2E
- -----o()o----------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (GNU/Linux)

iD8DBQFGbo+lq1ztTp5/Ti4RApULAJ9eCKY8+7+Oa7X4lt2hrAPOK5XX0ACfRl03
6Ti0/2u+BgqvM9n42H+Cksk=
=zrPV
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Do not modify ebuilds which are already in the tree... even if masked

[Markus Ullmann]

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

Luca Barbato schrieb:
> Another solution could be provide a nice script that does that for you...

Prefix project uses one already ;) Worth trying

Greetz
-jokey


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Sorry! WAS: Re: [gentoo-dev] Do not modify ebuilds which are already in the tree... even if masked

[cilly]

On Jun 12, 2007, at 2:14 PM, Carsten Lohrke wrote:

> Could you please stop spamming the list with your one sentence  
> replies!
> Waiting a day and then sending a single subsuming reply to the most  
> important
> arguments suffices completely. The mailing list is not a chat channel.
>
> Carsten

Hi list,

I am sorry, I did bother some of you.

May be I should have read the list-guidelines before.

Excuse me!

Cheers,

Cecilia

PS: I won't spam you in the future (ups sorry for my English)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Do not modify ebuilds which are already in the tree... even if masked

[Luca Barbato]

cilly wrote:
> On Jun 12, 2007, at 2:05 PM, Christian Faulhammer wrote:
> 
>>  You have the cvs diff abilites and we have a header that says which
>> CVS revision one is having.
> 
> Well, who are bugreporters? I'd say a lot of users report bugs who don't
> use CVS at all. And they even don't know about the different
> CVS-versions. Then a maintainer would have to ask for the CVS version...
> takes time, requires additional interaction which could be prevented, if
> the ebuild number is unique.

# $Header:
/var/cvsroot/gentoo-x86/media-video/ffmpeg/ffmpeg-0.4.9_p20050226-r3.ebuild,v
1.18 2007/02/12 11:19:58 vapier Exp $

that isn't that involving it's just run head on the ebuild ^^;

lu - anyway if is that simple it could be automated...

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Do not modify ebuilds which are already in the tree... even if masked

[Steve Long]

cilly wrote:
> On Jun 12, 2007, at 1:56 PM, Christoph Mende wrote:
> 
>> It seems a bit that you didn't fully understand that case. That
>> package
>> fails to install for 10% but works flawlessly for the other 90%. Those
>> 10% will get the fix even without a version bump, the other 90% don't,
>> but that's ok, they don't need it. A version bump would mean wasting
>> the time to recompile it for those 90%. I agree that there should be a
>> ChangeLog entry, but I think nearly all devs do that already :>
> 
> I did understand. But sometimes the mods could cause an error while
> reemerging for some of the 90%. We had that already.

No, you're missing the point; by not rev-bumping, that 90% don't get forced
to remerge. Honestly, the devs are just trying to avoid unnecessary
recompiles.
My advice is to log onto irc.freenode.org and ask these kinda questions in
#gentoo-dev-help as they'll explain if asked. If there is a valid use-case,
then you can post it as an enhancement request on bugzilla.
See http://www.gentoo.org/doc/en/bugzilla-howto.xml
http://www.gentoo.org/doc/en/index.xml has links to docs in other languages.


-- 
gentoo-dev@gentoo.org mailing list