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

[Marius Mauch]

On Tue, 12 Jun 2007 12:07:11 +0200
cilly <cilly@××××××××××.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.