Closed GoogleCodeExporter closed 8 years ago
This is the expected behaviour. Two packages can't provide the same file.
The discussion that you referenced addresses splitting providers of a file into
separate packages so that you can choose which package to install on each image.
An alternative approach would be have each package install the file to a
different patch and use update-alternatives to manage a link which may point to
one of them.
Original comment by paul.betafive
on 31 Oct 2014 at 11:17
The RPM package doesn't have this behavior, so that's why I'm proposing this.
Almost all of my projects I use opkg, but when I need to have different
packages providing the same files I have to switch to rpm.
Original comment by diego.su...@gmail.com
on 31 Oct 2014 at 11:24
How does this work in rpm? How do we choose which of the competing providers of
a file are used? And what if each package depends on the contents of the file
being what was included in that package?
If 'a' provides a file and we install 'b' which is now allowed to overwrite
that file, how do we guarantee that doesn't break 'a'?
Original comment by paul.betafive
on 31 Oct 2014 at 11:26
I understand your questions.
For example, the use case is: I want to install custom files (provided from
various packages) in a image.
Take a look at this:
https://github.com/wolfgar/meta-stef/blob/master/recipes-stef/images/xbmc-image.
bb
https://github.com/wolfgar/meta-stef/blob/master/recipes-stef/images/xbmc-image-
custom-rfs.bb
If I use rpm I can build the image but with opkg no.
Original comment by diego.su...@gmail.com
on 31 Oct 2014 at 11:37
Do you actually get any guarantees that the files from xbmc-image-custom-rfs
will be used though? I'm guessing that it just depends on the order that the
packages are listed in on the rpm command line.
If you upgrade or reinstall one of the packages that has a file overridden by
xbmc-image-custom-rfs, does the contents of the file change?
This sort of behaviour raises too many questions, especially for embedded
systems where we want reliable behaviour during an upgrade as there may not be
a human operator present to correct any problems. Therefore this isn't a
feature I'll be implementing in opkg.
Original comment by paul.betafive
on 31 Oct 2014 at 11:42
Ok Paul.
You are right. This raises a lot of potential problems.
Sorry, I cannot answer your questions right now.
Sorry about the buzz.
Original comment by diego.su...@gmail.com
on 31 Oct 2014 at 11:50
Original issue reported on code.google.com by
diego.su...@gmail.com
on 31 Oct 2014 at 11:09