[gentoo-dev] links between anoncvs.g.o and sources.g.o
Hi May I suggest that you add links so that anoncvs.g.o and sources.g.o link to one another. Users might find one of those pages and think that's all there is to it. However both of the pages contain information not available on the other. anoncvs.g.o mentions git and rsync, and sources.g.o allow viewing repo contents using your browser. -- Jonas
Re: [gentoo-dev] Re: bzr.eclass into Portage
Here is a patch that adds support for shared repositories. Since bzr
is still a bit slow this is quite useful when using multiple branches.
For example I have modified the live emacs(-cvs) ebuild to use the bzr
mirror of emacs instead of cvs. I also have my own emacs branches, and
sometimes want to install from one of these and at other times from
trunk. Without support for shared repositories this would require the
standalone branches to be manually moved out of the way everytime I
want to switch branches. (Or worse the complete tree to be checked out
from scratch every time I switch branches.)
Please consider these changes
Jonas
--- /usr/local/portage/layman/emacs/eclass/bzr.eclass 2008-10-05
22:40:18.0 +0200
+++ /usr/portage/eclass/bzr.eclass 2008-10-05 10:22:12.0 +0200
@@ -9,6 +9,7 @@
# @DESCRIPTION:
# The bzr.eclass provides support for apps using the bazaar DSCM
(distributed source control management system).
# The eclass was originally derived from the git eclass.
+# Shared repository support added by Jonas Bernoulli [EMAIL PROTECTED].
#
# Note: Just set EBZR_REPO_URI to the url of the branch and the src_unpack
# this eclass provides will put an export of the branch in ${WORKDIR}/${PN}.
@@ -22,13 +23,23 @@
HOMEPAGE=http://bazaar-vcs.org/;
DESCRIPTION=Based on the ${EBZR} eclass
-DEPEND==dev-util/bzr-0.92
+DEPEND==dev-util/bzr-1.6
# @ECLASS-VARIABLE: EBZR_STORE_DIR
# @DESCRIPTION:
# The dir to store the bzr sources.
EBZR_STORE_DIR=${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}/bzr-src
+# @ECLASS-VARIABLE: EBZR_SHARED_REPO
+# @DESCRIPTION:
+# Whether to use a shared repository (see bzr help repositories).
+EBZR_SHARED_REPO=${EBZR_SHARED_REPO:-}
+
+# @ECLASS-VARIABLE: EBZR_INIT_REPO_CMD
+# @DESCRIPTION:
+# The bzr command to initialize the shared repository.
+EBZR_INIT_REPO_CMD=bzr init-repo
+
# @ECLASS-VARIABLE: EBZR_FETCH_CMD
# @DESCRIPTION:
# The bzr command to fetch the sources.
@@ -54,9 +65,24 @@
# The bzr command to list revision number of the branch.
EBZR_REVNO_CMD=bzr revno
+# @ECLASS-VARIABLE: EBZR_INIT_REPO_OPTS
+# @DESCRIPTION:
+# Options passed to the init-repo commands.
+EBZR_INIT_REPO_OPTS=${EBZR_INIT_REPO_OPTS:-}
+
+# @ECLASS-VARIABLE: EBZR_FETCH_OPTS
+# @DESCRIPTION:
+# Options passed to the fetch commands in additon to EBZR_OPTIONS.
+EBZR_FETCH_OPTS=${EBZR_FETCH_OPTS:-}
+
+# @ECLASS-VARIABLE: EBZR_UPDATE_OPTS
+# @DESCRIPTION:
+# Options passed to the update commands in additon to EBZR_OPTIONS.
+EBZR_UPDATE_OPTS=${EBZR_UPDATE_OPTS:-}
+
# @ECLASS-VARIABLE: EBZR_OPTIONS
# @DESCRIPTION:
-# The options passed to the fetch and update commands.
+# The common options passed to the fetch and update commands.
EBZR_OPTIONS=${EBZR_OPTIONS:-}
# @ECLASS-VARIABLE: EBZR_REPO_URI
@@ -72,7 +98,7 @@
# - lp://
# @CODE
#
-# Note: lp = https://launchpad.net
+# Note: lp = http://launchpad.net
EBZR_REPO_URI=${EBZR_REPO_URI:-}
# @ECLASS-VARIABLE: EBZR_BOOTSTRAP
@@ -93,21 +119,26 @@
# @ECLASS-VARIABLE: EBZR_BRANCH
# @DESCRIPTION:
# The branch to fetch in bzr_fetch().
-#
-# default: trunk
-EBZR_BRANCH=${EBZR_BRANCH:-trunk}
+EBZR_BRANCH=${EBZR_BRANCH:-}
# @ECLASS-VARIABLE: EBZR_REVISION
# @DESCRIPTION:
# Revision to get, if not latest (see http://bazaar-vcs.org/BzrRevisionSpec)
EBZR_REVISION=${EBZR_REVISION:-}
-# @ECLASS-VARIABLE: EBZR_CACHE_DIR
+# @ECLASS-VARIABLE: EBZR_CACHE_REPO_DIR
# @DESCRIPTION:
-# The dir to store the source for the package, relative to EBZR_STORE_DIR.
+# The dir name of the local shared repository (if any).
#
# default: ${PN}
-EBZR_CACHE_DIR=${EBZR_CACHE_DIR:-${PN}}
+EBZR_CACHE_REPO_DIR=${EBZR_CACHE_REPO_DIR:-}
+
+# @ECLASS-VARIABLE: EBZR_CACHE_BRANCH_DIR
+# @DESCRIPTION:
+# The dir name of the local branch.
+#
+# default: ${EBZR_BRANCH} when using a shared repository or ${PN} otherwise
+EBZR_CACHE_BRANCH_DIR=${EBZR_CACHE_BRANCH_DIR:-}
# @FUNCTION: bzr_fetch
# @DESCRIPTION:
@@ -143,37 +174,64 @@
cd -P ${EBZR_STORE_DIR} || die ${EBZR}: can't chdir to
${EBZR_STORE_DIR}
- EBZR_BRANCH_DIR=${EBZR_STORE_DIR}/${EBZR_CACHE_DIR}
-
addwrite ${EBZR_STORE_DIR}
- addwrite ${EBZR_BRANCH_DIR}
- debug-print ${FUNCNAME}: EBZR_OPTIONS = ${EBZR_OPTIONS}
+ if [[ -n ${EBZR_SHARED_REPO} ]]; then
+ # using shared repository
+ EBZR_REPO_DIR=${EBZR_STORE_DIR}/${EBZR_CACHE_REPO_DIR:-${PN}}
+
EBZR_BRANCH_DIR=${EBZR_REPO_DIR}/${EBZR_CACHE_BRANCH_DIR:-${EBZR_BRANCH}}
+
+ addwrite ${EBZR_REPO_DIR}
+ else
+ # using stand-alone branch
+
EBZR_BRANCH_DIR=${EBZR_STORE_DIR}/${EBZR_CACHE_BRANCH_DIR:-${PN}}
+ fi
+
+ addwrite ${EBZR_BRANCH_DIR}
- local repository
+ local branch
- if [[ ${EBZR_REPO_URI} == */* ]]; then
- repository=${EBZR_REPO_URI}${EBZR_BRANCH}
+ if [[ -n ${EBZR_BRANCH} ]] ; then
+ branch=${EBZR_REPO_URI}/${EBZR_BRANCH}
else
Re: [gentoo-portage-dev] please explain use of hooks
On Sat, Mar 1, 2008 at 7:38 PM, Zac Medico [EMAIL PROTECTED] wrote: When portage is installed with USE=doc enabled, you'll find that there is a small Ebuild Phase Hooks section in the first chapter of the html documentation. thx. I never bothered looking there as I have always assumed that would just install the handbook. I have seen rather complex uses of hooks, that's why I thought it would be harder to get started. On Sun, Mar 2, 2008 at 2:27 AM, Alec Warner [EMAIL PROTECTED] wrote: Do not attribute to malice what can easily be attributed to laziness ;) yes sorry about that. Though I was not really all that lazy just made a really bad assumption. And if not the handbook this should really go into the portage manpage. bashrc If needed, this file can be used to set up a special environment for ebuilds, different from the standard root environment. The syntax is the same as for any other bash script. + One thing you can do here is define phase hooks. + A phase hook function name begins with a pre_ or post_ prefix to indicate that it will be called before or after one of the ebuild phases. The prefix is followed by the name of the ebuild function that the hook will be associated with. + For example, a hook named pre_src_compile will be called before src_compile, and a hook named post_src_compile will be called after src_compile. postsync.d should also be documented there. All in all now that I have looked at the documentation installed with portage I think it is obsolete. Not in the sense that it is outdated but everything in it is documented elsewhere already or should be moved there. II. Package Formats - 2. Ebuild - Ebuild Phases is already in the developer handbook and III. Quality Assurance - 3. QA Notices should be moved to the developer handbook If some developers an the list agree with me and welcome me to do so then I could file a bug(s) for those changes. --Jonas -- gentoo-portage-dev@lists.gentoo.org mailing list
[gentoo-portage-dev] please explain use of hooks
Hello I was aware that the alternative package managers provide hooks for some time now, but only found out recently that portage also has this feature. Unfortunately I was not able to find any documentation about it. I found some information related to hooks in portage on this list and elsewhere but all of those sources assumed that the reader already knows the basics. So what I am looking for is a tutorial along the lines howto write you first portage hook function. Of course a more in-depth description would also be welcome. If something like this already exists I apologize for not searching enough, and kindly ask you to point you to the location. The earlies post about hooks on this list seam to be from 2005, so I was a bit surprised I could not find any documentation about them. In my opinion this should be documented in the handbook. I can only assume that either no one found the time to write it or that hooks are intentionally not documented to prevent users from messing things up and then filling untraceable bug reports. So if later were the case I would still be very thankful if you could answer me in private, even though I think this should be documented in public. --Jonas -- gentoo-portage-dev@lists.gentoo.org mailing list
Re: R: [gentoo-portage-dev] manual uninstall
On 2/14/08, Lanza Fabrizio [EMAIL PROTECTED] wrote: I cannot issue a direct emerge command because catalyst does not support it. If the stage supports it you can use N/fsscript. Or if you want to unmerge the package at the beginning of the loop you could modify /usr/lib/catalyst/targets/stageN/stageN-chroot.sh. -- gentoo-portage-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] new portage categories
On 2/4/08, Donnie Berkholz [EMAIL PROTECTED] wrote: Sounds like what you really want are tags, not categories ... Yes and no. tags would definitely be better than subcategories. But for some packages a new category would probably still make sense like app-scm ( http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg27404.html). You could play with adding them into metadata.xml and patching some existing search tools to search for them. Added to my TODO list. Extending existing search tool would only be a first step however. The ability to exclude/include packages from the tree would also be a useful feature (and that doesn't seam to fit the design of the tools I have used). I'm all for the idea of tags, and I think it's a better approach than categories. Thinking about it again I would say tags and categories just fulfill different purposes. Tags can not replace categories but might be a useful extension to categories for the tasks I described, not more not less. They are not better or worse, just different:) -- Jonas -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] new portage categories
Hello Recently I started to exclude parts of the portage tree for various reasons. One of them is that I play with the thought of creating my own minidistro/livecd based on Gentoo. So keep in mind that I don't think that it is in general useful to trim the portage tree to the extend that I have. One of the obvious things one might start out with is to exclude kde when one prefers gnome or vice versa. I extended this to exclude packages within on category that fulfill the same purpose. E.g. I use app-admin/metalog so it doesn't make much sense to include all the other loggers. Since the decision for metalog at the time was not substantiated at the time a also made a note basically saying is metalog really the best? these are the alternatives. Once I have the time I might include the other loggers again and evaluate them. But to make the list of loggers I basically had to read through the descriptions of all packages in app-admin to sort out all loggers (I could have searched but I wanted to make sure I don't miss anything). Since I have not done this for loggers only this was/is a lot of work and I therefor asked myself why are there no categories like app-log or app-cron. So I ask you: why are there no such categories? Of course I can imagine a few reasons myself for not having more categories: (1) a category must in general include n packages (2) more categories are evil, once we start creating new once there is no end (3) moving packages in the tree is bad, things break (4) who does all the work (5) subcategories would be better, but to implement this... Please point me to any discussions on this subject. Keep in mind I am not demanding new categories, I am not even asking for them to be created. I simply would like to know why there aren't more. And if you developers are also interested in more categories I would love to make some suggestions and help with looking through the tree to see which packages would have to be moved. Reasons why more categories might be usefull: (1) Easier to find new packages One great benefit of going through the tree to exclude packages was for me that I came across many great packages I did not know about. The likeliness of this would be increased e.g. for the category app-admin, if I did not have to read the DESCRIPTION of ~8 loggers even though I already have selected one and currently am not at all interested in evaluating the alternatives. In addition there are ~14 logfile analysers of some sort in app-admin ~4 logfile rotators ~2 other log related packages. And some more can probably be found in app-misc, x11-apps and x11-misc. So all in all at least ~30 packages that have to do with logging, why not create app-log? (2) Easier to find alternatives to a package Need a logger? See what is in app-log! (3) Makes it less likely that similar packages end up in different categories Just an example app-admin/pwcrypt DESCRIPTION=An improved version of cli-crypt (encrypts data sent to it from the cli) but cli-crypt is in app-crypt By the way why is there app-crypt but not app-log? There are other things I noticed when weeding through the tree. E.g. some DESCRIPTIONs start with a capitalized letter others don't. Some end with a period, others don't. Some for now apparent reason start with foo is an application to do bar instead of do bar. I understand that it is not very interesting for any developer to fix such minor errors, and I am not asking anyone to do something about it. But I would like to know if there is any change that new categories are created if I or others collect lists of packages that could be moved to new categories. And yes I understand that the work doesn't end here and would possibly also help finding packages whose dependencies would have to be modified. For me also this is not exactly fun. But since I do this kind of work for my own personal benefit at the moment I might as well do it in a way that benefits others as well. -- Jonas -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] new portage categories
On 2/4/08, Donnie Berkholz [EMAIL PROTECTED] wrote: On 20:11 Mon 04 Feb , Jonas Bernoulli wrote: Thinking about it again I would say tags and categories just fulfill different purposes. Tags can not replace categories but might be a useful extension to categories for the tasks I described, not more not less. They are not better or worse, just different:) Why don't you think they can replace categories? Quick answer: Because there are packages with the same name in different categories. How would tags deal with that? Long answer: Well maybe there is a way. But I think that it would probably take a long time to make such a change. Technically tags could probably replace categories but then their would be no definite full name for that package anymore. Someone calls it foo/app and someone bar/app, and since there is also fuu/app which is a different application but with the same name, nobody would no for sure about package is being taked about without checking if his beloved foo/app is the same as bar/app the other guy is talking about. Also how do you sort the packages in the tree? all in one directory?! every package in the directories of each tag it belongs to using hardlinks? -- Jonas -- gentoo-dev@lists.gentoo.org mailing list
