On Tue, 12 Jun 2007 12:07:11 +0200 cilly <[EMAIL PROTECTED]> 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.
signature.asc
Description: PGP signature
