Mailinglist Archive: opensuse-buildservice (206 mails)

< Previous Next >
Re: [Kiwi-users] [opensuse-buildservice] kiwi's ignore element?
Hi Chris,

On 02/15/2011 02:28 PM, Chris Cunha wrote:
On Tue, Feb 15, 2011 at 7:14 AM, Marcus Schäfer <ms@xxxxxxx> 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_splash_images

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@xxxxxxxxxx
rschweikert@xxxxxxxxxx
781-464-8147

Novell
Making IT Work As One

--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups