dCore Import Debian Packages to Mountable SCE extensions > dCore X86

Conflicting package sources not properly handled

(1/4) > >>

sm8ps:
I want to import the package cherrytree which is available in version 0.32.0-1 from the main ubuntu trusty repository. I added ppa:vincent-c/cherrytree to debextra/ which provides version 0.35.9-1~ppa1~trusty1. It generates a file with the following content:
http://ppa.launchpad.net/vincent-c/cherrytree/ubuntu trusty main

Nevertheless, the package is taken from the official repository by sce-import and also sce-update does not recognize the more recent version from the ppa. -- Does anybody else experience similar behavior or is it just me again?    ::)

Jason W:
Most surely because of the trusty-security entry that is found in /opt/debextra before the vincent-c-cherokee.

Given this, I will call the security entris /opt/debextra/zzz-trusty-security to avoid this in the future as that needs to be the last file in all cases to be read by sce-import in /opt/debextra.

sm8ps:
I am not sure it is a matter of the security repos. The package is available from a regular repo; the ppa simply adds more recent versions.

--- Code: ---/mnt/sda8/tce$ grep cherrytree *
debinx.ubuntu-trusty-universe:Package: cherrytree
debinx.ubuntu-trusty-universe:Filename: pool/universe/c/cherrytree/cherrytree_0.32.0-1_all.deb
debinx.ubuntu-trusty-universe:Homepage: http://www.giuspen.com/cherrytree/
debinx.vincent-c-cherrytree-main:Package: cherrytree
debinx.vincent-c-cherrytree-main:Filename: pool/main/c/cherrytree/cherrytree_0.35.9-1~ppa1~trusty1_all.deb
--- End code ---

When I rename the debinx-file to zzz-debinx.ubuntu-trusty-universe sce-import fetches the right package. Though, such a work-around can only be applied if one knows about the different available versions.

sce-import seems to take the first available package. Is that correct? It would be desirable instead if it compared versions of all suitable packages. Is there a way to automate this other than manually renaming sources files?

For instance, I currently have the following debinx-files:

--- Code: ---debinx.enlightenment-git-ppa-ubuntu-trusty  debinx.ubuntu-trusty-multiverse           debinx.ubuntu-trusty-security-universe
debinx.midori-ppa-main                      debinx.ubuntu-trusty-restricted           debinx.ubuntu-trusty-universe
debinx.owncloud_client-opensuse             debinx.ubuntu-trusty-security-main        debinx.vincent-c-cherrytree-main
debinx.trusty-security                      debinx.ubuntu-trusty-security-multiverse
debinx.ubuntu-trusty-canonical_partner      debinx.ubuntu-trusty-security-restricted
--- End code ---

Jason W:
So zzz-trusty-security as a name works as expected.  I don't imagine any extra repos are going to have the hame zzzz- as a prefix, so that solution is the best given that the first repo is picked based on numeric first and then alphabetical order.  This gives you total control which repo you want to pull from in what order.

Comparing package versions would add much complexity on my end, especially considering there may be more than 2 to compare, and also take away your control of what repo you want to pull what package from.   And almost always the extra repos contain the newer package.

You won't have to manually rename the security files in /opt/debextra, I will in the base dCore-*.gz images.

sm8ps:

--- Quote from: Jason W on July 08, 2015, 09:53:32 AM ---Comparing package versions would add much complexity on my end, especially considering there may be more than 2 to compare, and also take away your control of what repo you want to pull what package from.   And almost always the extra repos contain the newer package.
--- End quote ---
That is what I expected. I will add this explanation to the wiki because it is important to know.


--- Quote from: Jason W on July 08, 2015, 09:53:32 AM ---You won't have to manually rename the security files in /opt/debextra, I will in the base dCore-*.gz images.
--- End quote ---
I still do not think that this solution is enough. In my case the "conflicting" repo, containing the obsolete package, is ubuntu-trusty-universe as opposed to a security repo. So there does not seem to be a way around manually "grading" repos alphabetically.

In this case I suggest to use a two digit numbered system instead of letters. So the security repos would become 90-trusty-security and the regular repos would become 80-trusty. That would give the flexibility to sort the repos in order of importance and also to easily juggle them around if need be. In my case, I would put all the ubuntu repos (universe, multiverse, restricted, canonical_partner) also into 80 and their corresponding security repos in 90 as there is no over-lap), the PPAs would go into the 50, say.

Navigation

[0] Message Index

[#] Next page