Re: [yoper-dev] [PACKAGERS] - Some hints to mass migrate
Hi all! With the help of TobiG I wrote a simple helper, for all those who need to update packages. Sometimes, as you all know, it's non-trivial to get all depencies or reverse depencies of a package - that's what this little helper will calculate for you. If you upgrade a package, the script will be able to find out which packages you also need to rebuild/update. Also it gives you a hint (reverse depencies) about which packages might break after your upgrade. You should always investigate that listing, because if any package that's part of the buildenvironment depends on the package you're trying to upgrade, the update might result in a broken buildenvironment. You might consult TobiG or me in such cases ;) To use that script, you have to do the following: checkout the whole rpmlookup svn tree at $SVNROOT/yoper/projects/rpmlookup copy the file $SVNROOT/yoper/projects/rpmlookup/Default.cfg to your homedir at: ~/.yoperbuild/rpmlookup/Default.cfg Modify the contents of the file: cache: should point to a file location holding the svn spec cache (that's just used to speed up lookups) svndir: should point to the local svn working copy of the spec files, namely $SVNROOT/yoper, usually containing 3.0, 3.1, devel, playground, projects and robots.text. Use path's only, no environment variables are supported. After that is done, you're ready for your first run of svnCacheLookup.py. The usage of that script should be self explanational. It does support the options -r and -d, -r meaning calculate reverse depencies, -d depencies. E.g. running svnCacheLookup.py -d bison will result in the following output: [EMAIL PROTECTED] ~/svn/yoper/projects/rpmlookup $ ./svnCacheLookup.py -d bison building cache from /home/armin/svn/yoper/3.0/rocketfuel done package bison found at: /home/armin/svn/yoper/3.0/rocketfuel/bison/bison.spec /home/armin/svn/yoper/3.0/rocketfuel/texinfo/texinfo.spec /home/armin/svn/yoper/3.0/rocketfuel/pkg-config/pkg-config.spec /home/armin/svn/yoper/3.0/rocketfuel/e2fsprogs/e2fsprogs.spec /home/armin/svn/yoper/3.0/rocketfuel/linux-libc-headers/linux-libc-headers.spec /home/armin/svn/yoper/3.0/rocketfuel/flex/flex.spec /home/armin/svn/yoper/3.0/rocketfuel/diffutils/diffutils.spec /home/armin/svn/yoper/3.0/rocketfuel/gawk/gawk.spec /home/armin/svn/yoper/3.0/rocketfuel/autoconf/autoconf.spec /home/armin/svn/yoper/3.0/rocketfuel/automake/automake.spec /home/armin/svn/yoper/3.0/rocketfuel/automake16/automake16.spec /home/armin/svn/yoper/3.0/rocketfuel/libtool/libtool.spec /home/armin/svn/yoper/3.0/rocketfuel/gcc-opt/gcc-opt.spec /home/armin/svn/yoper/3.0/rocketfuel/gpm/gpm.spec /home/armin/svn/yoper/3.0/rocketfuel/ncurses/ncurses.spec /home/armin/svn/yoper/3.0/rocketfuel/readline/readline.spec /home/armin/svn/yoper/3.0/rocketfuel/gmp/gmp.spec /home/armin/svn/yoper/3.0/rocketfuel/which/which.spec /home/armin/svn/yoper/3.0/rocketfuel/binutils/binutils.spec /home/armin/svn/yoper/3.0/rocketfuel/yopermaintain/yopermaintain.spec /home/armin/svn/yoper/3.0/rocketfuel/gcc/gcc.spec /home/armin/svn/yoper/3.0/rocketfuel/m4/m4.spec /home/armin/svn/yoper/3.0/rocketfuel/bison/bison.spec Found 22 depencies You can also redirect the output to a file with the shell, only the paths are printed to stdout, all other output goes to stderr and is therefore leftout in normal redirection. Notice the direction of the output, it shows the package depending on the given package that's at the highest depth in the depency graph, meaning you should update packages in the exact order that's printed here. Another thing about what package names are supported: actually all. The internal cache of the script is built using all (sub-)package definitions and provides of a spec file, so e.g. calculating depencies of qt4-devel will in fact calculate those for qt4 instead. Keep that in mind. I hope that this little script is useful - TobiG and me will continue developing it much further. Regards Armin Kazmi ___ yoper-dev mailing list yoper-dev@lists.yoper.com http://lists.frank-hosting.de/cgi-bin/mailman/listinfo/yoper-dev
Re: [yoper-dev] [PACKAGERS] - Some hints to mass migrate
Hi Tobias,
good mini-guide. However, not to break the normal rule, I have a few questions:
Date: Tue, 18 Dec 2007 07:07:34 +1300
From: [EMAIL PROTECTED]
To: yoper-dev@lists.yoper.com
Subject: [yoper-dev] [PACKAGERS] - Some hints to mass migrate
Hi,
As this is the first time we do that in this configuration I'd like to
suggest a certain approach.
1) Do not migrate more than 20 packages at once ( svn cp )
I think one bye one is even better. Migrating packages from 3.0 to 3.1 is not
such a direct task, even more taking into account that g++ is not now in gcc
package and that we have to upgrade quite old packages. We have also to
remember that neither .la files nor buildroot is working in the same way.
2) Make things in small steps
a) copy package A
b) bump release and get a successful build done for package A
c) test new package briefly and confirm functionality
How is it supposed to do this having Yoper 3.0 in our machines? Aren't packages
for 3.1 incompatible for 3.0?
d) update package to latest stable version and get a successful build done
e) update dependencies of this package A if necessary
Is there any rule of thumb to do this? When should a dependency be considered
that must be rebuilt or might be affected by the new build?
3) move to package B
If you hit problems with a package that is not in your maintainership
contact the maintainer or the mailing list and give 24 hours time to
respond before proceeding.
Packages that do not have a current maintainer need to get the vacant tag.
Some suggestions how to do things in detail. We have some useful
helpers in our svn tree to make things a bit easier:
1) svn-cp-tree.sh , copies a whole bunch of projects into --targetdir
it supports --dry-run to test the command
When used it copies the mentioned projects and performs a svn ci -m
'commitonly' of all packages that are successfully copied.
Here an example :
~/versioncontrol/svn/yoper/projects/errata/svn-cp-tree.sh
--targetdir=../../3.1/rocketfuel/ aMule abiword acpid add airsnort
alien alltray alsa-utils amsn appres apt4rpm aquamarine arping ash
aspell at-spi atftp athcool aufs autoconf261 automake110 automake16
autotrace
Just simply note the revision number somewhere and you can always look
back via svn log -v -rREVNO to see which packages you copied :) .
2) bump-buildreq.sh
Use this to bump the release of packages that depend on a certain
package. For example if you'd like to bump all packages in
3.1/rocketfuel that are build against sqlite execute :
~/versioncontrol/svn/yoper/projects/errata/bump-buildreq.sh sqlite-devel
This will bump the release of those packages by 1 and generate a svn
command that you can simply copy and paste.
it supports --dry-run to test the command
3) bump-release.sh
This script bumps projects that are appended to it as arguments.
it supports --dry-run to test the command
This allows you to selectively bump the release of some packages
Say you want to first see where sqlite-devel is included :
grep -l sqlite-devel */*.spec | awk -F '/' '{print $1}'
This will return you some project names where you might not want to
bump all packages but only a few.
That is where script (3) is useful simply run
bump-release.sh 'your list of projects to bump release'
I hope this helps a bit to decrease the workload and simplify the
task. More input welcome.
cheers
Cheers x 2! :-)
--
Tobias Gerschner
Member of Board of Yoper Linux Ltd. NZ
Knowing is not enough; we must apply. Willing is not enough; we must do.
___
yoper-dev mailing list
yoper-dev@lists.yoper.com
http://lists.frank-hosting.de/cgi-bin/mailman/listinfo/yoper-dev
_
Tecnología, moda, motor, viajes,…suscríbete a nuestros boletines para estar
siempre a la última
http://newsletters.msn.com/hm/maintenanceeses.asp?L=ESC=ESP=WCMaintenanceBrand=WLRU=http%3a%2f%2fmail.live.com
___
yoper-dev mailing list
yoper-dev@lists.yoper.com
http://lists.frank-hosting.de/cgi-bin/mailman/listinfo/yoper-dev
Re: [yoper-dev] [PACKAGERS] - Some hints to mass migrate
2007/12/18, Carlos López [EMAIL PROTECTED]:
Hi Tobias,
good mini-guide. However, not to break the normal rule, I have a few
questions:
Date: Tue, 18 Dec 2007 07:07:34 +1300
From: [EMAIL PROTECTED]
To: yoper-dev@lists.yoper.com
Subject: [yoper-dev] [PACKAGERS] - Some hints to mass migrate
Hi,
As this is the first time we do that in this configuration I'd like to
suggest a certain approach.
1) Do not migrate more than 20 packages at once ( svn cp )
I think one bye one is even better. Migrating packages from 3.0 to 3.1 is not
such a direct task, even more taking into account that g++ is not now in gcc
package and that we have to upgrade quite old packages. We have also to
remember that neither .la files nor buildroot is working in the same way.
Yes, this is true. The number 20 was the upper limit I was suggesting.
Choose less if you're more comfortable with that. There will be 20
packages that you migrate within a hour while the next 20 packages
might take a week.
The problem is more avoiding that we all start migrating the same
packages. Maybe a quick mail when doing mass migration of some
packages would help to avoid that. I started mass migration with a* .
Another catch is , that we have to look in those 20 packages now and
make sure we migrate their dependencies first.
2) Make things in small steps
a) copy package A
b) bump release and get a successful build done for package A
c) test new package briefly and confirm functionality
How is it supposed to do this having Yoper 3.0 in our machines? Aren't
packages for 3.1 incompatible for 3.0?
d) update package to latest stable version and get a successful build
done
e) update dependencies of this package A if necessary
Is there any rule of thumb to do this? When should a dependency be considered
that must be rebuilt or might be affected by the new build?
Major version update or when you see that when installing a new
version of a package would uninstall some other packages. If there's
no version update you generally don't need to rebuild any packages.
3) move to package B
If you hit problems with a package that is not in your maintainership
contact the maintainer or the mailing list and give 24 hours time to
respond before proceeding.
Packages that do not have a current maintainer need to get the vacant tag.
Some suggestions how to do things in detail. We have some useful
helpers in our svn tree to make things a bit easier:
1) svn-cp-tree.sh , copies a whole bunch of projects into --targetdir
it supports --dry-run to test the command
When used it copies the mentioned projects and performs a svn ci -m
'commitonly' of all packages that are successfully copied.
Here an example :
~/versioncontrol/svn/yoper/projects/errata/svn-cp-tree.sh
--targetdir=../../3.1/rocketfuel/ aMule abiword acpid add airsnort
alien alltray alsa-utils amsn appres apt4rpm aquamarine arping ash
aspell at-spi atftp athcool aufs autoconf261 automake110 automake16
autotrace
Just simply note the revision number somewhere and you can always look
back via svn log -v -rREVNO to see which packages you copied :) .
2) bump-buildreq.sh
Use this to bump the release of packages that depend on a certain
package. For example if you'd like to bump all packages in
3.1/rocketfuel that are build against sqlite execute :
~/versioncontrol/svn/yoper/projects/errata/bump-buildreq.sh sqlite-devel
This will bump the release of those packages by 1 and generate a svn
command that you can simply copy and paste.
it supports --dry-run to test the command
3) bump-release.sh
This script bumps projects that are appended to it as arguments.
it supports --dry-run to test the command
This allows you to selectively bump the release of some packages
Say you want to first see where sqlite-devel is included :
grep -l sqlite-devel */*.spec | awk -F '/' '{print $1}'
This will return you some project names where you might not want to
bump all packages but only a few.
That is where script (3) is useful simply run
bump-release.sh 'your list of projects to bump release'
I hope this helps a bit to decrease the workload and simplify the
task. More input welcome.
cheers
Cheers x 2! :-)
--
Tobias Gerschner
Member of Board of Yoper Linux Ltd. NZ
Knowing is not enough; we must apply. Willing is not enough; we must do.
___
yoper-dev mailing list
yoper-dev@lists.yoper.com
http://lists.frank-hosting.de/cgi-bin/mailman/listinfo/yoper-dev
_
Tecnología, moda, motor, viajes,…suscríbete a nuestros boletines para estar
siempre a la última
http://newsletters.msn.com/hm/maintenanceeses.asp?L=ESC=ESP=WCMaintenanceBrand=WLRU=http%3a%2f%2fmail.live.com
cheers
Re: [yoper-dev] [PACKAGERS] - Some hints to mass migrate
2007/12/18, Carlos López [EMAIL PROTECTED]: Thanks for your really quick replies. You missed question 2c) 2) Make things in small steps a) copy package A b) bump release and get a successful build done for package A c) test new package briefly and confirm functionality How is it supposed to do this having Yoper 3.0 in our machines? Aren't packages for 3.1 incompatible for 3.0? Yes they are. Guess I'll write a wiki page how to upgrade then :) . cheers Tobias -- Tobias Gerschner Member of Board of Yoper Linux Ltd. NZ Knowing is not enough; we must apply. Willing is not enough; we must do. ___ yoper-dev mailing list yoper-dev@lists.yoper.com http://lists.frank-hosting.de/cgi-bin/mailman/listinfo/yoper-dev
