[opensuse-buildservice] kiwi's ignore element?
I don't see a "kiwi" ML so I'll try here for some help with this. In my config.xml (kiwi file) I have a bunch of branding files that are going to replace the existing Suse branding files. I have a list of packages and a list of patterns that are to be installed. Since my branding package is to replace (and conflict) with the Suse version of it, the build will fail if the equivalent Suse branding package is being installed also. Although the Suse package isn't actually in the list of packages it is part of the "lxde" pattern. I read in the kiwi doc pdf file that reads "If a pattern contains unwanted packages, you can use the ignore element to specify an ignore list, with the name attribute containing the package name." I can't find any examples as to how to use this 'ignore' element within my config.xml file. Any help on this would be much appreciated. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On 02/14/2011 05:14 PM, Chris Cunha wrote:
I don't see a "kiwi" ML
kiwi-users@lists.berlios.de
so I'll try here for some help with this. In my config.xml (kiwi file) I have a bunch of branding files that are going to replace the existing Suse branding files. I have a list of packages and a list of patterns that are to be installed. Since my branding package is to replace (and conflict) with the Suse version of it, the build will fail if the equivalent Suse branding package is being installed also. Although the Suse package isn't actually in the list of packages it is part of the "lxde" pattern. I read in the kiwi doc pdf file that reads "If a pattern contains unwanted packages, you can use the ignore element to specify an ignore list, with the name attribute containing the package name." I can't find any examples as to how to use this 'ignore' element within my config.xml file. Any help on this would be much appreciated.
<packages> .... <ignore name="THE_PACKAGE_YOU_WANT_TO_IGNORE"/> ..... </packages> The schema documentation is in: /usr/share/doc/packages/kiwi/schema/kiwi.html installed with the kiwi-doc package. Point your browser at this file and things should be fairly obvious. HTH, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Novell-IBM Software Integration Center LINUX Tech Lead rschweikert@novell.com rschweikert@ca.ibm.com 781-464-8147 Novell Making IT Work As One -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Thanks Robert very much for all the information.
I inserted the this line within the rest of the package section.
<packages type="image" patternType="onlyRequired">
<package name="wdiff"/>
<package name="lockdev"/>
<ignore name="lxde-common-branding-openSUSE"/>
</packages>
Despite this line being inserted into the package list this SUSE
package still conflicts with my branding package. If I disable
(comment out) the pattern "lxde" this issue goes away, however there
are other packages from the "lxde" patter that I need. This has
happened some other packages as well. I really hopeing that the
"ignore" element would work to finally resolve this issue. Any idea
what's going on here. Is my syntax incorrect in my example?
Chris
I will post further kiwi related questions to the kiwi ML.
On Mon, Feb 14, 2011 at 5:21 PM, Robert Schweikert
On 02/14/2011 05:14 PM, Chris Cunha wrote:
I don't see a "kiwi" ML
kiwi-users@lists.berlios.de
so I'll try here for some help with this. In my config.xml (kiwi file) I have a bunch of branding files that are going to replace the existing Suse branding files. I have a list of packages and a list of patterns that are to be installed. Since my branding package is to replace (and conflict) with the Suse version of it, the build will fail if the equivalent Suse branding package is being installed also. Although the Suse package isn't actually in the list of packages it is part of the "lxde" pattern. I read in the kiwi doc pdf file that reads "If a pattern contains unwanted packages, you can use the ignore element to specify an ignore list, with the name attribute containing the package name." I can't find any examples as to how to use this 'ignore' element within my config.xml file. Any help on this would be much appreciated.
<packages> .... <ignore name="THE_PACKAGE_YOU_WANT_TO_IGNORE"/> ..... </packages>
The schema documentation is in:
/usr/share/doc/packages/kiwi/schema/kiwi.html
installed with the kiwi-doc package. Point your browser at this file and things should be fairly obvious.
HTH, Robert
-- Robert Schweikert MAY THE SOURCE BE WITH YOU Novell-IBM Software Integration Center LINUX Tech Lead rschweikert@novell.com rschweikert@ca.ibm.com 781-464-8147
Novell Making IT Work As One -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hi Chris, Please subscribe to kiwi-users@lists.berlios.de and lets move the discussion to the kiwi list. This really has nothing to do with the build service. Plus the discussion might be useful to other Kiwi users that are not on the build service list. On 02/14/2011 08:58 PM, Chris Cunha wrote:
Thanks Robert very much for all the information. I inserted the this line within the rest of the package section.
<packages type="image" patternType="onlyRequired"> <package name="wdiff"/> <package name="lockdev"/> <ignore name="lxde-common-branding-openSUSE"/> </packages> Despite this line being inserted into the package list this SUSE package still conflicts with my branding package. If I disable (comment out) the pattern "lxde" this issue goes away, however there are other packages from the "lxde" patter that I need.
The <ignore> element does not work because the conflicting package is "hidden" in a pattern. zypper knows about pattern names and how to find them, thus, Kiwi does not need to build a list of packages inside a pattern. This implies that Kiwi never sees the "lxde-common-branding-openSUSE" name as a package and therefore it cannot be removed/ignored.
This has happened some other packages as well. I really hopeing that the "ignore" element would work to finally resolve this issue. Any idea what's going on here.
See above.
Is my syntax incorrect in my example?
The syntax is correct. You can try the replace attribute, i.e. <package name="MY_BRANDING_PACKAGE" replaces="xde-common-branding-openSUSE"/> Packages with the "replaces" attribute are handled differently than the <ignore> elements. HTH, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Novell-IBM Software Integration Center LINUX Tech Lead rschweikert@novell.com rschweikert@ca.ibm.com 781-464-8147 Novell Making IT Work As One -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hi,
<packages type="image" patternType="onlyRequired"> <package name="wdiff"/> <package name="lockdev"/> <ignore name="lxde-common-branding-openSUSE"/> </packages> Despite this line being inserted into the package list this SUSE package still conflicts with my branding package. If I disable (comment out) the pattern "lxde" this issue goes away, however there are other packages from the "lxde" patter that I need.
The <ignore> element does not work because the conflicting package is "hidden" in a pattern. zypper knows about pattern names and how to find them, thus, Kiwi does not need to build a list of packages inside a pattern. This implies that Kiwi never sees the "lxde-common-branding-openSUSE" name as a package and therefore it cannot be removed/ignored.
This is correct. I implemented the ignore element for the packages list only. When using another than the zypper packagemanager kiwi resolves the patterns itself (using satsolver) and in the result list you can ignore packages which are not pulled in by a hard requirement. With zypper we just pass the pattern name and let zypper do all the rest which has the downside that we cannot influence what is going to be installed in a pattern. The only solution here is to add the package into the delete section <packages type="delete"> <package name="lxde-common-branding-openSUSE"/> </packages> and make sure your config.sh includes the following function call: suseRemovePackagesMarkedForDeletion Regards, Marcus -- Public Key available gpg --keyserver gpg-keyserver.de --recv-keys 0xCCE3C6A2 ------------------------------------------------------- Marcus Schäfer (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg GF: Markus Rex HRB: 16746 (AG Nürnberg) http://www.suse.de Germany ------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tue, Feb 15, 2011 at 7:14 AM, Marcus Schäfer
Hi,
<packages type="image" patternType="onlyRequired"> <package name="wdiff"/> <package name="lockdev"/> <ignore name="lxde-common-branding-openSUSE"/> </packages> Despite this line being inserted into the package list this SUSE package still conflicts with my branding package. If I disable (comment out) the pattern "lxde" this issue goes away, however there are other packages from the "lxde" patter that I need.
The <ignore> element does not work because the conflicting package is "hidden" in a pattern. zypper knows about pattern names and how to find them, thus, Kiwi does not need to build a list of packages inside a pattern. This implies that Kiwi never sees the "lxde-common-branding-openSUSE" name as a package and therefore it cannot be removed/ignored.
This is correct. I implemented the ignore element for the packages list only. When using another than the zypper packagemanager kiwi resolves the patterns itself (using satsolver) and in the result list you can ignore packages which are not pulled in by a hard requirement. With zypper we just pass the pattern name and let zypper do all the rest which has the downside that we cannot influence what is going to be installed in a pattern. The only solution here is to add the package into the delete section
<packages type="delete"> <package name="lxde-common-branding-openSUSE"/> </packages>
and make sure your config.sh includes the following function call:
suseRemovePackagesMarkedForDeletion
Regards, Marcus -- Public Key available gpg --keyserver gpg-keyserver.de --recv-keys 0xCCE3C6A2 ------------------------------------------------------- Marcus Schäfer (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg GF: Markus Rex HRB: 16746 (AG Nürnberg) http://www.suse.de Germany ------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
This is my last post on this subject in this mailing list. I apologize to the Build Service ML about this off subject post. I've sent an email to subscribe to the Kiwi ML but haven't received a reply yet. Robert S. If you have any way to speed up my subscription to this ML please do. None of the last few suggestions have worked. I'm a bit confused on this issue. Isn't this rebrand situation one of the more common uses for Kiwi? I would have thought that replacing a default SUSE package with and OEM branding package would be fairly common, no? I was told by at least 3 Novell guys that the "delete" section is used to remove the package during the configuration of the installed OS. So anything added to the "delete" section (in the config.xml/kiwi file) will not have any effect on this problem as this problem has to do with the package being installed by the pattern in the image's "prepare" stages of the build. Also it appears that adding the line " suseRemovePackagesMarkedForDeletion" as suggested will also have no effect on this issue as that script (config.sh) runs after the packages are "installed" in the "prepare" stage of the kiwi image build. What I am very surprised with is that the "replaces" element added to the package line doesn't work either. That was really disappointing. I thought for sure this would work. The other thing that makes no sense is how clearly the kiwi docs .pdf file states that if this problem exists...then use the "ignore" element to resolve it. So does this mean that I now have to add each package that each pattern contains and leave out the ones that are being replaced by our OEM packages? If so how can we confirm EXACTLY what packages are contained in the pattern package? I've tried Yast GUI under Patterns. This proved to be not an accurate means of packages contained in the pattern. Is the rule of thumb that if your doing a rebrand of SUSE you can't use Patterns in your config.xml /kiwi file? I noticed (before this branding/replacement issue) that having patterns in the config.xml file would cause another unwanted issue and that is after the final ISO image is made and your using the installed iso/image that you just made with Kiwi if you open Yast's GUI Package Manager it will got out and try to install tons of packages that were intentionally left out of the package list in my config.xml file. So even though only the packages that I wanted were installed (I can confirm this by just looking around in the working OS) when Yast is opened it wants to download/upgrade all the packages that were in the patterns.....I guess that's where it's getting this list from. So, what is the best way to confirm what packages are contained in the patterns. I guess I'll just remove the patterns completely. Thanks guys, Chris -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hi Chris, On 02/15/2011 02:28 PM, Chris Cunha wrote:
On Tue, Feb 15, 2011 at 7:14 AM, Marcus Schäfer
wrote: Hi,
<packages type="image" patternType="onlyRequired"> <package name="wdiff"/> <package name="lockdev"/> <ignore name="lxde-common-branding-openSUSE"/> </packages> Despite this line being inserted into the package list this SUSE package still conflicts with my branding package. If I disable (comment out) the pattern "lxde" this issue goes away, however there are other packages from the "lxde" patter that I need.
The <ignore> element does not work because the conflicting package is "hidden" in a pattern. zypper knows about pattern names and how to find them, thus, Kiwi does not need to build a list of packages inside a pattern. This implies that Kiwi never sees the "lxde-common-branding-openSUSE" name as a package and therefore it cannot be removed/ignored.
This is correct. I implemented the ignore element for the packages list only. When using another than the zypper packagemanager kiwi resolves the patterns itself (using satsolver) and in the result list you can ignore packages which are not pulled in by a hard requirement. With zypper we just pass the pattern name and let zypper do all the rest which has the downside that we cannot influence what is going to be installed in a pattern. The only solution here is to add the package into the delete section
<packages type="delete"> <package name="lxde-common-branding-openSUSE"/> </packages>
and make sure your config.sh includes the following function call:
suseRemovePackagesMarkedForDeletion
This is my last post on this subject in this mailing list. I apologize to the Build Service ML about this off subject post. I've sent an email to subscribe to the Kiwi ML but haven't received a reply yet. Robert S. If you have any way to speed up my subscription to this ML please do.
None of the last few suggestions have worked. I'm a bit confused on this issue. Isn't this rebrand situation one of the more common uses for Kiwi?
Maybe yes, but I do not know. For re-branding people may not necessarily create their own packages, but rather use the method documented here: http://en.opensuse.org/SDB:KIWI_Cookbook_Splash_Screen#Custom_GRUB_and_boot_... Thus, there are no packaging conflicts. Further the branding packages are generally separate as in bootsplash-branding-openSUSE gfxboot-branding-openSUSE rather than being part of a pattern. You are running into trouble because the definition of the LXDE pattern includes the branding packages. These branding packages for some reason or another cause a conflict. However, that there is a conflict sounds fishy to begin with. I suspect that your branding packages are putting files in the same location as the distribution supplied packages and that's why the conflict is triggered. Different branding packages should put their files into different directories, then there is no opportunity for conflicts. Anyway, I am going on a "clean up the world" tangent now and will stop.
I would have thought that replacing a default SUSE package with and OEM branding package would be fairly common, no?
Probably, as mentioned above the packages are separate by default and thus in the "common" case one just does not install the openSUSE branding packages. The problem is the pattern.
I was told by at least 3 Novell guys that the "delete" section is used to remove the package during the configuration of the installed OS. So anything added to the "delete" section (in the config.xml/kiwi file) will not have any effect on this problem as this problem has to do with the package being installed by the pattern in the image's "prepare" stages of the build.
Yes, delete happens after the install.
Also it appears that adding the line " suseRemovePackagesMarkedForDeletion" as suggested will also have no effect on this issue as that script (config.sh) runs after the packages are "installed" in the "prepare" stage of the kiwi image build.
What I am very surprised with is that the "replaces" element added to the package line doesn't work either. That was really disappointing. I thought for sure this would work. The other thing that makes no sense is how clearly the kiwi docs .pdf file states that if this problem exists...then use the "ignore" element to resolve it.
I will take a look at the doc and re-word it to make this less ambiguous. I'll submit a patch for this.
So does this mean that I now have to add each package that each pattern contains and leave out the ones that are being replaced by our OEM packages?
Yes, and no. You can take the approach of basically expanding the list of packages that are part of the pattern in the config.xml file. However, the root cause is really not the use of the pattern but rather the packages that cause the conflict. If I were in your shoes I would work on understanding why the packages conflict and then fix the conflicts, I know back to "clean up the world" mode. If you just have newer versions of things that are already there you can just give your packages higher version numbers. The package manager will pick them up automatically and you do not have to list them in config.xml at all.
If so how can we confirm EXACTLY what packages are contained in the pattern package?
Information about patterns are found in suse/setup/descr/ on the media. I do not know where the source of the patterns resides, probably somewhere in the buildservice.
I've tried Yast GUI under Patterns. This proved to be not an accurate means of packages contained in the pattern. Is the rule of thumb that if your doing a rebrand of SUSE you can't use Patterns in your config.xml /kiwi file?
No, this is a problem with the LXDE pattern. IMHO, the LXDE pattern should not contain the branding packages, but at the same token your own branding packages should not put files into locations used by packages that get delivered with the distribution.
I noticed (before this branding/replacement issue) that having patterns in the config.xml file would cause another unwanted issue and that is after the final ISO image is made and your using the installed iso/image that you just made with Kiwi if you open Yast's GUI Package Manager it will got out and try to install tons of packages that were intentionally left out of the package list in my config.xml file. So even though only the packages that I wanted were installed (I can confirm this by just looking around in the working OS) when Yast is opened it wants to download/upgrade all the packages that were in the patterns.....I guess that's where it's getting this list from.
A couple of thoughts on this. First if you are building your image without including the online update repositories, or an up to date local copy thereof, then you should expect the package manager to tell you about available updates if the updates repo is configured. If you don't configure the updates repo on the system you are building then you will not have this issue. Second, you probably have a difference between recommended and required packages. In your config.xml file I suspect you use patternType="onlyRequired". Then when you fire up the package manager on your image it will probably look for the recommended packages as well. Thus, you get a list of additional packages to install. I do not know how to tell the YaST package manager via configuration to ignore recommended packages. Another role in this is obviously played by the configured repositories in your image. If you do not configure any repos then the package manager has nothing to pull packages from. Thus your update strategy has a major impact on this behavior.
So, what is the best way to confirm what packages are contained in the patterns.
Look in the pattern definition, see above where to find it. HTH, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Novell-IBM Software Integration Center LINUX Tech Lead rschweikert@novell.com rschweikert@ca.ibm.com 781-464-8147 Novell Making IT Work As One -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hi Chris,
None of the last few suggestions have worked. I'm a bit confused on this issue. Isn't this rebrand situation one of the more common uses for Kiwi?
Maybe yes, but I do not know. For re-branding people may not necessarily create their own packages, but rather use the method documented here:
http://en.opensuse.org/SDB:KIWI_Cookbook_Splash_Screen#Custom_GRUB_and_boot_...
People want custom branding, yes but most of them rebrand by just overwriting data as described in the article Robert posted. Even though it is much more clean to create a branding package one needs to take care for some branding package specific 'rules' which I will write down later in this mail
Thus, there are no packaging conflicts. Further the branding packages are generally separate as in
bootsplash-branding-openSUSE gfxboot-branding-openSUSE
rather than being part of a pattern. You are running into trouble because the definition of the LXDE pattern includes the branding packages.
These branding packages for some reason or another cause a conflict. However, that there is a conflict sounds fishy to begin with. I suspect that your branding packages are putting files in the same location as the distribution supplied packages and that's why the conflict is triggered. Different branding packages should put their files into different directories, then there is no opportunity for conflicts. Anyway, I am going on a "clean up the world" tangent now and will stop.
It's perfectly fine to have multiple branding packages installed _but_ each of them have to provide an own theme name. Example: a) bootsplash-branding-openSUSE ==> installs to: /etc/bootsplash/themes/openSUSE Theme Name: openSUSE ==> in kiwi config.xml <boot-theme>openSUSE</boot-theme> b) bootsplash-branding-SLES ==> install to: /etc/bootsplash/themes/SLES Theme Name: SLES ==> in kiwi config.xml <boot-theme>SLES</boot-theme> c) Your branding package ==> install to: /etc/bootsplash/themes/YourBranding Theme Name: YourBranding ==> in kiwi config.xml <boot-theme>YourBranding</boot-theme> If your branding package follow these rules there will be no conflict and you can easily use it by just selecting the theme in <boot-theme> So the question I have is: where do your package install the files rpm -qpl "Your branding package"
I would have thought that replacing a default SUSE package with and OEM branding package would be fairly common, no?
Probably, as mentioned above the packages are separate by default and thus in the "common" case one just does not install the openSUSE branding packages. The problem is the pattern.
What is the oem branding package ?
What I am very surprised with is that the "replaces" element added to the package line doesn't work either. That was really disappointing. I thought for sure this would work. The other thing that makes no sense is how clearly the kiwi docs .pdf file states that if this problem exists...then use the "ignore" element to resolve it.
I will take a look at the doc and re-word it to make this less ambiguous. I'll submit a patch for this.
I will add that patch today. 'replaces', replaces one ore more packages with another package but this doesn't have any impact on the previos package dependency and conflict creation of the package manager. If you put a branding package into your package list which conflicts with another package this conflict always will be reported because the very first and prio1 task is to make sure that the specified package list is conflict free. replaces and delete happens after the packagemanager thought about the package list. I can't change this because the packagemanager backend (zypper in our case) always wants a clean list which it didn't get and so it errors out. The ignore statement is processed before the package list is passed to the package manager but as I said in case of patterns we leave it up to the package manager to solve them and so the ignore doesn't have an impact on the contents of patterns if zypper is used
So does this mean that I now have to add each package that each pattern contains and leave out the ones that are being replaced by our OEM packages?
Yes, and no. You can take the approach of basically expanding the list of packages that are part of the pattern in the config.xml file. However, the root cause is really not the use of the pattern but rather the packages that cause the conflict. If I were in your shoes I would work on understanding why the packages conflict and then fix the conflicts, I know back to "clean up the world" mode.
I completely agree, solve the package conflict
If so how can we confirm EXACTLY what packages are contained in the pattern package?
Information about patterns are found in suse/setup/descr/ on the media. I do not know where the source of the patterns resides, probably somewhere in the buildservice.
You can let kiwi solve the list for you: kiwi --info /path/to/image/description --select packages it will print the list of solved packages. This also requires that the specified package list is conflict free. If there is a conflict, the conflict will be reported. But again I strongly recommend to fix the package causing the conflict. We are not talking about a kiwi bug or inconvenience that's all cause by a packaging problem. By the way I didn't receive the exact error message you got from the package manager. I would be glad to assist in solving the issue here on the list This will also help others Regards, Marcus -- Public Key available gpg --keyserver gpg-keyserver.de --recv-keys 0xCCE3C6A2 ------------------------------------------------------- Marcus Schäfer (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstrasse 5 FAX: 0911-740 53 479 D-90409 Nürnberg GF: Markus Rex HRB: 16746 (AG Nürnberg) http://www.suse.de Germany ------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (3)
-
Chris Cunha
-
Marcus Schäfer
-
Robert Schweikert