 |
 |
|
[ << ] [ < ] [ Home ] [ > ] [ >> ] 5. Ebuild Maintenance HOWTOContent:5.a. Introduction This guide aims to explain common everyday ebuild maintenance routines, as well as other rarer maintenance routines which developers may not be familiar with. 5.b. Stabilizing ebuilds When adding a new ebuild, you should only include KEYWORDS for architectures on which you have actually tested the ebuild, confirming that it works as it should and that USE flags are properly honoured in the resulting package which would be installed. If possible, you should give the actual library or application thorough testing as well, since you would be responsible for any breakages for your architecture(s). Minimal testing such as checking that the application starts up without any errors should always be performed. If you are adding a user-submitted ebuild, do not assume that the submitter has done testing on various architectures: often, KEYWORDS are cloned across packages or generated from documentation in the source packages, which does not signify that the package does indeed work on those architectures. Ebuilds should only be stabilized, i.e. placed from "~arch" into "arch" when the maintainer, or an architecture maintainer deems the ebuild to be stable. You should never stabilize packages on architectures for which you cannot test and instead you should file a bug to the relevant architecture team, such as sparc@gentoo.org asking them to stabilize the ebuild. Alternatively, you may be able to find Gentoo developers on IRC who could help you with your request. It is best to not use arch-maintainers@gentoo.org, adding architecture teams onto a bug's CC list individually instead. That way teams can remove themselves from the list when they are done, giving a clear indication of which teams still have to stabilize a package. 5.c. Upgrading ebuilds New ebuilds should rarely go in with "arch" keywords and even if they do not, the package must be tested on any architectures listed in the KEYWORDS variable of the new ebuild. Exceptions to the no "arch" rule are major bug fixes, or security fixes. If the previous version of the ebuild contains KEYWORDS which you cannot test for, you should downgrade them: turn any "arch" keyword to "~arch". If you think that your package may not work at all even on "~arch" then it is best to leave the keyword out and request testing from the relevant team: if you are to do this, you must file a bug to the team in question. If a new version introduces new dependencies which are not available on some architectures, then you should file a bug or ask on IRC before you upgrade the package. If you really need to get the ebuild added in a hurry, for example, for a security fix, then you should drop any KEYWORDS which are causing problems and CC the relevant architectures on the bug - you should file a new bug to the architecture in question regarding this if no bug is already available. If there are no new dependencies, do not remove keywords if your commit fails with repoman - please try a full cvs update and if you still have problems, then commit with repoman -I and file a bug to the broken architecture, noting it in your CVS commit message.
5.d. Moving ebuilds Moving ebuilds is a two-step process: Firstly, you need to move the ebuild in CVS. To do this, you should copy the ebuild to its new location and commit that as you would with a new ebuild. After this, you should change any ebuilds which DEPEND on the old ebuild to depend on the new one. Only after this, you should remove each of the files with cvs remove in the old location and commit the changes there.
Alternatively; you can use epkgmove which will do this for you:
Once moved, you should add an entry to the latest file in profiles/updates/ in the Portage tree in the following format:
This example would transparently move net-misc/fwbuilder to net-firewall/fwbuilder if users have it installed. This way, users would now automatically receive updates for net-firewall/fwbuilder when they are available. 5.e. Removing ebuilds When removing an ebuild make sure that no dependencies in Portage are broken due to the removal - additionally, your CVS commit message should explain clearly why the ebuild is being removed from CVS. If you need to remove ebuilds, make sure you do not accidentally remove the newest/only stable ebuild for any architecture. If you would like to get a newer version marked stable, then please file a bug or ask on IRC. You should also not cause an unnecessary downgrade for any "~arch" when removing ebuilds - instead, it is best to get the newest version marked "~arch" first and then remove redundant versions of the ebuild. [ << ] [ < ] [ Home ] [ > ] [ >> ] The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. |
|
