Ebuild Maintenance

Date: Sat, 11 Apr 2015 13:32:56 +0200 Subject: Promote "Ebuild Maintenance" from subsection to section. Bug 546006. --- ebuild-maintenance/text.xml | 487 +++++++++++++++++++++++++++++ ebuild-writing/common-mistakes/text.xml | 2 +- ebuild-writing/ebuild-maintenance/text.xml | 487 ----------------------------- ebuild-writing/text.xml | 1 - text.xml | 1 + 5 files changed, 489 insertions(+), 489 deletions(-) create mode 100644 ebuild-maintenance/text.xml delete mode 100644 ebuild-writing/ebuild-maintenance/text.xml diff --git a/ebuild-maintenance/text.xml b/ebuild-maintenance/text.xml new file mode 100644 index 0000000..7325b66 --- /dev/null +++ b/ebuild-maintenance/text.xml @@ -0,0 +1,487 @@ + + + +Ebuild Maintenance + + +

+This guide aims to explain common everyday ebuild maintenance +routines, as well as other rarer maintenance routines which +developers may not be familiar with. +

+ +

+Adding a new ebuild + + + +What (not) to put in the Portage tree + + +

+Before writing a new ebuild, check +bugs.gentoo.org +to see if an ebuild has already been written for the package, but has not yet +been added to the Portage tree. Go to bugs.gentoo.org, choose query and select +Advanced Search; as product select Gentoo Linux, as component select +ebuilds. In the search field put the name of the ebuild and as status +select NEW, ASSIGNED, REOPENED and RESOLVED (RESOLVED is important), then +submit the query. For you lazy people, click here. +

+ +

+In general, the Portage tree should only be used for storing +.ebuild files, as well as any relatively small companion +files, such as patches or sample configuration files. These types of +files should be placed in the /usr/portage/mycat/mypkg/files +directory to keep the main mycat/mypkg directory uncluttered. +Exceptions to this rule are for larger patch files (we recommend this for patches +above 20KB) which should be distributed as tarballs via the +Gentoo mirror system +so that people do not waste excessive amounts of bandwidth and hard drive +space. Also, you should not add binary (non-ASCII) files to the +Portage CVS tree. If you need to do this in another CVS tree, for +example, if you need to add a small PNG graphic for whatever reason, +be sure to add it to CVS by using the -kb option, like so: +

+ +

+# cvs add -kb myphoto.png
+

+ +

+The -kb option tells CVS that myphoto.png is a binary +file and should be treated specially. For example, merging the +differences between two different versions of this file should not be +allowed to happen, for obvious reasons. Also, speaking of merging +changes, any patches you add to Portage should generally not be +compressed. This will allow CVS to merge changes and correctly inform +developers of conflicts. +

+ +

+Remember, the packages that you commit must be ready out of the +box for end users when committed as stable. Make sure that you have a good +set of default settings that will satisfy the majority of systems and +users that will use your package. If your package is broken, and you are +not sure how to get it to work, check some other distributions that have +done their own versions of the package. You can check +Mandriva +or Debian or +Fedora for some +examples. +

+ +

+When committing to CVS, all developers should use repoman commit +instead of cvs commit to submit their ebuilds. Before committing, +please run repoman full to make sure you didn't forget something. +

+ + + + + +Initial Architecture Keywords + +

+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. +

+ + + + + +CVS Commit Policy + + +

Always run repoman scan before you commit.
Please run repoman full before you commit.
Always test that package.mask is okay by doing +emerge --pretend mypkg before you commit and check +that it doesn't contain any conflicts.
Always update the ChangeLog before you commit.
Always commit the updated package.mask before +the updated package, in case conflicts occur while you commit +package.mask.
Always do atomic commits; if you commit a package with a new license, +or that is masked, then first commit the revised package.mask and/or license, +then commit the ebuild, ChangeLog, patches +and metadata.xml all in one go +to avoid breaking users' installations.

+ + + + + +The files Directory + + +

+As noted earlier, under each package subdirectory is +a files/ directory. Any patches, configuration files, or +other ancillary files your package might require should be added to +this directory; any files bigger than 20KB-or-so should go to the +mirrors to lower the amount of (unneeded) files our users have to +download. You may want to consider naming patches you create yourself +just to get your package to build with a version-specific name, such +as mypkg-1.0-gentoo.diff, or more +simply, 1.0-gentoo.diff. Also note that the +gentoo extension informs people that this patch was created +by us, the Gentoo Linux developers, rather than having been grabbed from a +mailing list or somewhere else. Again, you should not compress these +patches because CVS does not play well with binary files. +

+ +

+Consider prefixing or suffixing (such as mypkg-1.0) every file +you put into the files/ directory, so that the files used for +each individual version on an ebuild are distinguishable from one another, and +so that the changes between different revisions are visible. This is generally +a really good idea :). You may want to use a different suffix if you wish to +convey more meaning with the patch name. +

+ +

+If you have many files that should go into the files/ directory, +consider creating subdirectories such as files/1.0/ and putting the +relevant files in the appropriate subdirectory. If you use this method, +you do not need to add version information to the names of the files, +which is often more convenient. +

+ + + + + +

+ +

+Touching other developers ebuilds + +

Usually you don't just change other developers ebuilds without permission unless you know that developer does not mind or if you are part of the herd involved in maintenance (this information can typically be found in metadata.xml). Start with filing a bug or trying to catch them on IRC or via email. Sometimes you cannot reach them, or there is no response to your bug. It's a good idea to consult other developers on how to handle the situation, especially if it's a critical issue that needs to be handled ASAP. Otherwise a soft limit of 2 to 4 weeks depending on the severity of the bug is an acceptable time frame before you go ahead and fix it yourself.

+ Common sense dictates to us that toolchain/base-system/core packages and eclasses or anything else which is delicate (e.g. glibc) or widely used (e.g. gtk+) should usually be left to those maintainers. If in doubt, don't touch it. + +

+ +

+Stabilizing ebuilds + + +

+Only architecture maintainers for a given architecture should mark packages as +stable on that architecture. The maintainer of the package should always be +contacted just in case there are reasons not to do so. The exception to this +is if you are part of an architecture team, in which case you may mark the +package stable for that architecture. If you are not part of an architecture +team, you should consult the guidelines below; if the architecture you are +looking for is not listed then please consult the relevant lead. +

+ +

+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. +

+ + +

+ +

+Stabilization rules + + +

+SPARC: You must have prior permission from the arch lead. Usually we expect +you to be on the sparc alias for QA reasons, although other arrangements +can be made if you will only be working with a small group of packages. +

+ +

+ALPHA: Maintainers may keyword their own packages but are reminded to inform +the Alpha team if they can help out with testing and keywording packages so +the team can keep an eye out for possible keywording mistakes. +

+ +

+Exotic architectures (like alpha, ia64, sparc, hppa, ppc*) are short on manpower, so it's best if you avoid opening stabilization bugs for them unless it is absolutely necessary (eg, a reverse dependency for your package). More about keywording policies can be found in the keywording section. +

+Some architectures (like m68k, mips, s390, sh) do not maintain a stable keyword. So there is no use in marking a package stable for one of these architectures. +

+ +

+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. +

+ + +When committing, make sure that you reference any bugs in the +ChangeLog as well as the CVS message. Failing to do so is considered +to be in very poor taste and may result in disciplinary action. + + + +

+ +

+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. After this, should add an entry to the +latest file in profiles/updates/ in the Portage tree in the in +the following format: +

+ +

+move net-misc/fwbuilder net-firewall/fwbuilder
+

+ +

+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. +

+ +

+Once this step is concluded, you are allowed to remove the old package. +Simply issue a cvs remove -Rf $PN in the package category and commit +the changes afterwards with a meaningful commit message. Don't forget to update +entries in files such as profiles/package.mask to reflect the new category. Finally +remember to change the title to open bugs related to this package if needed. +

+ +

+net-misc # cvs rm -Rf fwbuilder
+cvs remove: use `cvs commit' to remove these files permanently
+net-misc # cvs ci -m "Moving net-misc/fwbuilder to net-firewall/fwbuilder."
+

+ + +CVS cannot destroy directories: it will simply not re-create them if +they are blank, providing you use CVS with the -P flag. + + + +

+ +

+Changing ebuild's SLOT + +

+The process for changing the ebuild's SLOT is very similar to the previous process. +Besides changing the SLOT in the ebuild file, you also need to create a new entry +in profiles/updates/ in the Portage tree in the following format: +

+ +

+slotmove app-text/gtkspell 0 2
+

+ +

Make sure that you have fixed all the reverse dependencies and that you have +updated every file in profiles/ directory that happens to contain an +entry which may be affected by your change. +

+ + +

+ +

+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. +

+ + +

+ +

+Removing a package + + +

+When removing packages follow these steps: +

+ +

Make sure that no dependencies in Portage are broken due to the removal
Send last rites to gentoo-dev-announce and gentoo-dev
Mask the package
Wait 30 days (or more)
Remove from CVS unless the reason for removal has been fixed
Remove package.mask entry
Close open bugs as WONTFIX

+ +

+In order to remove a package completely from CVS, delete any files from the +directory and commit this, CVS will take care of removing empty directories +itself. +

+ +

# cd app-admin
+# cvs rm -Rf scotty
+# cvs ci -m "app-admin/scotty removal (pending 21st July 2006), see #77501 for reference." scotty

+ + +

+ +

+Conflicting files + + +

+When you encounter a package that is trying to install files that are +already provided by another package (detectable with +FEATURES=collision-protect for example) you have to fix this +situation before you can commit the ebuild or, if you encounter this +with an existing package, file a bug about that package (see below for +a few exceptions). The reason file conflicts are critical is because +if "foo" provides the file /usr/bin/example and "bar" is +going to overwrite it, and later "bar" is unmerged, Portage will remove +/usr/bin/example and it is therefore likely it will break +"foo". +

+ +

+The most obvious fix is to add a blocking dependency to both packages +that want to install that file, so they can't be installed at the same +time. But unless there are also other reasons for those packages to +block each other you should avoid this if possible and rather fix the +package, which could include one or more of the following steps: +

+ +

Make "foo" (R)DEPEND on "bar" and not install the conflicting + file.
Remove conflicting files from "foo" in src_install + or pkg_preinst.
Move conflicting files into a new subpackage and make "foo" and + "bar" both (R)DEPEND on that package.
Change the location where "foo" or "bar" installs conflicting + files.

+ +

+In some cases conflicting files can't be really fixed or aren't +critical, currently known exceptions are Perl module manpages +(overwriting the ones from Perl itself) and CONFIG_PROTECT'ed +files (which should still be fixed, but aren't critical as Portage +won't overwrite them). +

+ + +

+ +

+Homepage unavailable + + +

+If the HOMEPAGE of your package seems to be unavailable or it +never existed at all, please set the HOMEPAGE variable in every ebuild +to +https://wiki.gentoo.org/wiki/No_homepage +

+ + +

+ + + + diff --git a/ebuild-writing/common-mistakes/text.xml b/ebuild-writing/common-mistakes/text.xml index ff906fd..9c6b423 100644 --- a/ebuild-writing/common-mistakes/text.xml +++ b/ebuild-writing/common-mistakes/text.xml @@ -432,7 +432,7 @@ at least when the ebuild hits the stable branch.

Please submit ebuilds properly by following the Adding new Ebuild tutorial. +link="::ebuild-maintenance#adding-a-new-ebuild">Adding new Ebuild tutorial.

diff --git a/ebuild-writing/ebuild-maintenance/text.xml b/ebuild-writing/ebuild-maintenance/text.xml deleted file mode 100644 index 4fa3a8b..0000000 --- a/ebuild-writing/ebuild-maintenance/text.xml +++ /dev/null @@ -1,487 +0,0 @@ - - - -Ebuild Maintenance - - -

-This guide aims to explain common everyday ebuild maintenance -routines, as well as other rarer maintenance routines which -developers may not be familiar with. -

- -

-Adding a new ebuild - - - -What (not) to put in the Portage tree - - -

-Before writing a new ebuild, check -bugs.gentoo.org -to see if an ebuild has already been written for the package, but has not yet -been added to the Portage tree. Go to bugs.gentoo.org, choose query and select -Advanced Search; as product select Gentoo Linux, as component select -ebuilds. In the search field put the name of the ebuild and as status -select NEW, ASSIGNED, REOPENED and RESOLVED (RESOLVED is important), then -submit the query. For you lazy people, click here. -

- -

-In general, the Portage tree should only be used for storing -.ebuild files, as well as any relatively small companion -files, such as patches or sample configuration files. These types of -files should be placed in the /usr/portage/mycat/mypkg/files -directory to keep the main mycat/mypkg directory uncluttered. -Exceptions to this rule are for larger patch files (we recommend this for patches -above 20KB) which should be distributed as tarballs via the -Gentoo mirror system -so that people do not waste excessive amounts of bandwidth and hard drive -space. Also, you should not add binary (non-ASCII) files to the -Portage CVS tree. If you need to do this in another CVS tree, for -example, if you need to add a small PNG graphic for whatever reason, -be sure to add it to CVS by using the -kb option, like so: -

- -

-# cvs add -kb myphoto.png
-

- -

-The -kb option tells CVS that myphoto.png is a binary -file and should be treated specially. For example, merging the -differences between two different versions of this file should not be -allowed to happen, for obvious reasons. Also, speaking of merging -changes, any patches you add to Portage should generally not be -compressed. This will allow CVS to merge changes and correctly inform -developers of conflicts. -

- -

-Remember, the packages that you commit must be ready out of the -box for end users when committed as stable. Make sure that you have a good -set of default settings that will satisfy the majority of systems and -users that will use your package. If your package is broken, and you are -not sure how to get it to work, check some other distributions that have -done their own versions of the package. You can check -Mandriva -or Debian or -Fedora for some -examples. -

- -

-When committing to CVS, all developers should use repoman commit -instead of cvs commit to submit their ebuilds. Before committing, -please run repoman full to make sure you didn't forget something. -

- - - - - -Initial Architecture Keywords - -

-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. -

- - - - - -CVS Commit Policy - - -

Always run repoman scan before you commit.
Please run repoman full before you commit.
Always test that package.mask is okay by doing -emerge --pretend mypkg before you commit and check -that it doesn't contain any conflicts.
Always update the ChangeLog before you commit.
Always commit the updated package.mask before -the updated package, in case conflicts occur while you commit -package.mask.
Always do atomic commits; if you commit a package with a new license, -or that is masked, then first commit the revised package.mask and/or license, -then commit the ebuild, ChangeLog, patches -and metadata.xml all in one go -to avoid breaking users' installations.

- - - - - -The files Directory - - -

-As noted earlier, under each package subdirectory is -a files/ directory. Any patches, configuration files, or -other ancillary files your package might require should be added to -this directory; any files bigger than 20KB-or-so should go to the -mirrors to lower the amount of (unneeded) files our users have to -download. You may want to consider naming patches you create yourself -just to get your package to build with a version-specific name, such -as mypkg-1.0-gentoo.diff, or more -simply, 1.0-gentoo.diff. Also note that the -gentoo extension informs people that this patch was created -by us, the Gentoo Linux developers, rather than having been grabbed from a -mailing list or somewhere else. Again, you should not compress these -patches because CVS does not play well with binary files. -

- -

-Consider prefixing or suffixing (such as mypkg-1.0) every file -you put into the files/ directory, so that the files used for -each individual version on an ebuild are distinguishable from one another, and -so that the changes between different revisions are visible. This is generally -a really good idea :). You may want to use a different suffix if you wish to -convey more meaning with the patch name. -

- -

-If you have many files that should go into the files/ directory, -consider creating subdirectories such as files/1.0/ and putting the -relevant files in the appropriate subdirectory. If you use this method, -you do not need to add version information to the names of the files, -which is often more convenient. -

- - - - - -

- -

-Touching other developers ebuilds - -

- Common sense dictates to us that toolchain/base-system/core packages and eclasses or anything else which is delicate (e.g. glibc) or widely used (e.g. gtk+) should usually be left to those maintainers. If in doubt, don't touch it. - -

- -

-Stabilizing ebuilds - - -

-Only architecture maintainers for a given architecture should mark packages as -stable on that architecture. The maintainer of the package should always be -contacted just in case there are reasons not to do so. The exception to this -is if you are part of an architecture team, in which case you may mark the -package stable for that architecture. If you are not part of an architecture -team, you should consult the guidelines below; if the architecture you are -looking for is not listed then please consult the relevant lead. -

- -

-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. -

- - -

- -

-Stabilization rules - - -

-SPARC: You must have prior permission from the arch lead. Usually we expect -you to be on the sparc alias for QA reasons, although other arrangements -can be made if you will only be working with a small group of packages. -

- -

-ALPHA: Maintainers may keyword their own packages but are reminded to inform -the Alpha team if they can help out with testing and keywording packages so -the team can keep an eye out for possible keywording mistakes. -

- -

-Exotic architectures (like alpha, ia64, sparc, hppa, ppc*) are short on manpower, so it's best if you avoid opening stabilization bugs for them unless it is absolutely necessary (eg, a reverse dependency for your package). More about keywording policies can be found in the keywording section. -

-Some architectures (like m68k, mips, s390, sh) do not maintain a stable keyword. So there is no use in marking a package stable for one of these architectures. -

- -

-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. -

- - -When committing, make sure that you reference any bugs in the -ChangeLog as well as the CVS message. Failing to do so is considered -to be in very poor taste and may result in disciplinary action. - - - -

- -

-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. After this, should add an entry to the -latest file in profiles/updates/ in the Portage tree in the in -the following format: -

- -

-move net-misc/fwbuilder net-firewall/fwbuilder
-

- -

-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. -

- -

-Once this step is concluded, you are allowed to remove the old package. -Simply issue a cvs remove -Rf $PN in the package category and commit -the changes afterwards with a meaningful commit message. Don't forget to update -entries in files such as profiles/package.mask to reflect the new category. Finally -remember to change the title to open bugs related to this package if needed. -

- -

-net-misc # cvs rm -Rf fwbuilder
-cvs remove: use `cvs commit' to remove these files permanently
-net-misc # cvs ci -m "Moving net-misc/fwbuilder to net-firewall/fwbuilder."
-

- - -CVS cannot destroy directories: it will simply not re-create them if -they are blank, providing you use CVS with the -P flag. - - - -

- -

-Changing ebuild's SLOT - -

-The process for changing the ebuild's SLOT is very similar to the previous process. -Besides changing the SLOT in the ebuild file, you also need to create a new entry -in profiles/updates/ in the Portage tree in the following format: -

- -

-slotmove app-text/gtkspell 0 2
-

- -

Make sure that you have fixed all the reverse dependencies and that you have -updated every file in profiles/ directory that happens to contain an -entry which may be affected by your change. -

- - -

- -

-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. -

- - -

- -

-Removing a package - - -

-When removing packages follow these steps: -

- -

Make sure that no dependencies in Portage are broken due to the removal
Send last rites to gentoo-dev-announce and gentoo-dev
Mask the package
Wait 30 days (or more)
Remove from CVS unless the reason for removal has been fixed
Remove package.mask entry
Close open bugs as WONTFIX

- -

-In order to remove a package completely from CVS, delete any files from the -directory and commit this, CVS will take care of removing empty directories -itself. -

- -

# cd app-admin
-# cvs rm -Rf scotty
-# cvs ci -m "app-admin/scotty removal (pending 21st July 2006), see #77501 for reference." scotty

- - -

- -

-Conflicting files - - -

-When you encounter a package that is trying to install files that are -already provided by another package (detectable with -FEATURES=collision-protect for example) you have to fix this -situation before you can commit the ebuild or, if you encounter this -with an existing package, file a bug about that package (see below for -a few exceptions). The reason file conflicts are critical is because -if "foo" provides the file /usr/bin/example and "bar" is -going to overwrite it, and later "bar" is unmerged, Portage will remove -/usr/bin/example and it is therefore likely it will break -"foo". -

- -

-The most obvious fix is to add a blocking dependency to both packages -that want to install that file, so they can't be installed at the same -time. But unless there are also other reasons for those packages to -block each other you should avoid this if possible and rather fix the -package, which could include one or more of the following steps: -

- -

Make "foo" (R)DEPEND on "bar" and not install the conflicting - file.
Remove conflicting files from "foo" in src_install - or pkg_preinst.
Move conflicting files into a new subpackage and make "foo" and - "bar" both (R)DEPEND on that package.
Change the location where "foo" or "bar" installs conflicting - files.

- -

-In some cases conflicting files can't be really fixed or aren't -critical, currently known exceptions are Perl module manpages -(overwriting the ones from Perl itself) and CONFIG_PROTECT'ed -files (which should still be fixed, but aren't critical as Portage -won't overwrite them). -

- - -

- -

-Homepage unavailable - - -

-If the HOMEPAGE of your package seems to be unavailable or it -never existed at all, please set the HOMEPAGE variable in every ebuild -to -https://wiki.gentoo.org/wiki/No_homepage -

- - -

- - - - diff --git a/ebuild-writing/text.xml b/ebuild-writing/text.xml index 1107a9b..2f55b47 100644 --- a/ebuild-writing/text.xml +++ b/ebuild-writing/text.xml @@ -30,5 +30,4 @@ with some general notes and extended examples. - diff --git a/text.xml b/text.xml index c2c89b0..4044e0d 100644 --- a/text.xml +++ b/text.xml @@ -39,6 +39,7 @@ section lists specific contributions to this manual. + -- cgit v1.2.3-65-gdbad