Am Dienstag, 22. Dezember 2009 02:38:33 schrieb Jian Lee:
Hi, Adrian
Thank you very much !
But I have two questions:
1. Does the "Ignore" used as following in /srv/obs/projects/<MyProject>.conf ?
yes
---------------------------------------------- Ignore: initscripts:kernel,udev,ethtool,mingetty Ignore: tetex:tetex-fonts,desktop-file-utils Ignore: pam:glib2 Ignore: libraw1394:kernel
Ignore: gettext-devel:libgcj,libstdc++-devel Ignore: pam-modules:resmgr Ignore: rpm:suse-build-key,build-key Ignore: bind-utils:bind-libs Ignore: alsa:dialog,pciutils Ignore: portmap:syslogd Ignore: fontconfig:freetype2 Ignore: fontconfig-devel:freetype2-devel Ignore: xorg-x11-libs:freetype2 =================================
for example, what's the meaning of "Ignore: fontconfig:freetype2"? and "Ignore: alsa:dialog,pciutils" ?
It means to ignore the dependency to freetype2 from fontconfig package. So, freetype2 will not get installed if it just get pulled by fontconfig.
2. How to "high chances to break your distro"? Is that means I should to stop building all pkgs in my distro?
No, that the built packages may not be compatible to each other. Esp. when you submit changes in multiple packages (but can also happen with a single changed package). bye adrian
"And if you don't know why the cyclces are there (or that many and large) you have also high chances to break your distro."
Thanks, all
Monday 21 December 200921:28:31Adrian Schröter
写道: Am Montag, 21. Dezember 2009 14:22:00 schrieb Petit Eric:
2009/12/21 Petit Eric
: you cannot "manage" this with the build and publish flags ? Perhaps at the end it will cost less time ? http://picpaste.com/pics/Capture-5.1261401374.png
Because my suggestion could be confuse here it is more details, idea should be to disable all build and/or publish, use an worksheet to list all order dependency, build the package at the highest level, publish it, once published, disable it again, build the second package, etc, then when all dependency packages are build, published and disable, enable all other packages.
this is a even more horrible workaround.
Best solution is to reduce the cycles as much as possible. Working around the cycle handling only means that you have high chances to get broken packages.
And if you don't know why the cyclces are there (or that many and large) you have also high chances to break your distro.
If you know why they are there, you should be able also to break them for example via "Ignore:" statements in your project configuration in a valid way.
as usual, this has absolut nothing to do with monoosc so it can't be used to solve the problem.
bye adrian
-- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org