Mailinglist Archive: opensuse-buildservice (206 mails)

< Previous Next >
Re: [Kiwi-users] [opensuse-buildservice] kiwi's ignore element?
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_splash_images

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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >