- How to exclude certain files from a package?
- About installing dependencies.
- How do do 'cvc scs --ls changset.file', but with rmake?
- Don't create symbol links by hand
- How to revert a package to its older version
- How to know from which :source trove is a package built
- cvc cook succeeds but rmake build fails
- Generate 'major version' from the whole version string
- shadow vs. clone
How to exclude certain files from a package?
For example, to make several versions of automake be able to install side-by-side, only one of them may install /usr/bin/automake.
I don't know yet.
About installing dependencies.
When you are cooking and find something missing, take care when you issue right away a 'sudo conary update blahblah'. According to your context, it may pull things from places which you don't mean to. For example this happens here when it pulls qt4:devel=4.5.2 from fl:2-devel and results in a bunch of conflicts with existing qt4:lib=4.5.1.
How do do 'cvc scs --ls changset.file', but with rmake?
<jesse> how can i view the file list of a pkg built in rmake?
<jesse> i.e. something like 'cvc scs --ls'
<pscott> jesse: "repositoryMap narsil.home http://localhost:7777/conary/" in conaryrc
<pscott> with whatever hostname you want
<pscott> then you can do 'conary rq --ls nini=narsil.home@local:2-devel'
Don't create symbol links by hand
For example the Makefile contains
install:
ln -sf $(MAINDIR)$(EXECFILE) $(BINDIR)$(NAME)
And it expands into something like,
ln -sf /home/jyr/conary/builds/tucan/ROOT/share/tucan/tucan.py /home/jyr/conary/builds/tucan/ROOT/bin/tucan
Then cvc would give such an error:
error: DanglingSymlinks: Dangling symlink: /bin/tucan points to non-existant ../home/jyr/conary/builds/tucan/ROOT/share/tucan/tucan.py (/home/jyr/conary/builds/tucan/ROOT/share/tucan/tucan.py)
So, comment out that 'ln' line(use a patch), and use r.Symlink to create the symbol link,
r.Symlink('%(datadir)s/tucan/tucan.py', '%(bindir)s/tucan')
How to revert a package to its older version
Sometimes you committed a package but it's broken (or makes others broken), then you may want to revert your commit (so as not to block a group promote, to disturb the users, etc.) To do the reverting, you can simply 'promote' ('man cvc' to read more) the old version, e.g. I updated banshee to 1.5.1-0.2 and wanted it back to 1.5.0-0.1,
$ cvc promote banshee:source=1.5.0-0.1 :2-devel--:2-devel The following clones will be created: Clone banshee:source (/foresight.rpath.org@fl:devel//2-devel/1.5.0-0.2) continue with clone? [y/N] y
Now you can build and commit the binary.
Note: to do a commit you must be at the head of the branch, or else you will see such an error,
$ cvc ci error: contents of working directory are not all from the head of the branch; use update
As a result, "cvc update <oldversion>; cvc commit" won't do the commit; neither will "cvc checkout <package>=<oldversion>; cd <package>; cvc commit".
How to know from which :source trove is a package built
Use 'conary rq --info' (not 'conary q --info'),
$ conary rq udev --info Name : udev Build time: Fri Apr 17 02:06:16 2009 Version : 116-4.2-1 Label : conary.rpath.com@rpl:2-qa ... Source : udev:source ...
cvc cook succeeds but rmake build fails
<mkj_wk> in general, "works with cvc cook but fails with rmake" has a few possible categories of reasons:
<mkj_wk> 1) insufficient buildRequires (generally when it is something conary does not (yet) know how to autodiscover)
<mkj_wk> 2) different versions of some of the software on the system running cvc vs. the rmake build root
<mkj_wk> 3) something environmental, like the build depends on the running kernel or hardware specifics
Generate 'major version' from the whole version string
At times, you may want to split out the 'major version number' from a version, e.g. to download a package which puts all 3.1.x releases under a "3.1" directory. This is plain and simple python, but it's no bad to write it down here, for easy reference (:
name = 'ethos'
version = '0.2.0'
def unpack(r):
r.macros.majversion = '.'.join(r.version.split('.')[:2])
r.addArchive('http://ftp.dronelabs.com/sources/%(name)s/%(majversion)s/')
shadow vs. clone
<JohnWelborn> if a product on rbuilder, other than from rpath or foresight contain an older version of something I want, is it better to shadow it or clone it? <JohnWelborn> in the case of rpath contrib I heard I should clone <OgMaciel> I'd say clone <doniphon> depends on if it maintained at the original source and if so if you want to track changes there (if so - shadow better) <JohnWelborn> if its a fairly old version I would think that its not maintained <doniphon> clone