* PREFERRED_VERSION and wildcards @ 2012-03-14 21:34 Andreas Oberritter 2012-03-14 22:54 ` Martin Jansa 0 siblings, 1 reply; 4+ messages in thread From: Andreas Oberritter @ 2012-03-14 21:34 UTC (permalink / raw) To: bitbake-devel Hi, I just tried using wildcards, like it's done for gcc, e.g.: PREFERRED_VERSION_foo = "1.2%" Now, if I have two foo recipes, foo_1.2.1.bb and foo_1.2.3.bb, in the same directory, then Bitbake always chooses 1.2.1 instead of the one with the higher version number. Does bitbake always choose the first matching version it can find? Is this a general limitation of wildcards, or is this a problem that can get corrected? I'd expect it to choose the highest matching version. Regards, Andreas ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: PREFERRED_VERSION and wildcards 2012-03-14 21:34 PREFERRED_VERSION and wildcards Andreas Oberritter @ 2012-03-14 22:54 ` Martin Jansa 2012-03-14 23:53 ` Andreas Oberritter 0 siblings, 1 reply; 4+ messages in thread From: Martin Jansa @ 2012-03-14 22:54 UTC (permalink / raw) To: Andreas Oberritter; +Cc: bitbake-devel [-- Attachment #1: Type: text/plain, Size: 1899 bytes --] On Wed, Mar 14, 2012 at 10:34:59PM +0100, Andreas Oberritter wrote: > Hi, > > I just tried using wildcards, like it's done for gcc, e.g.: > > PREFERRED_VERSION_foo = "1.2%" > > Now, if I have two foo recipes, foo_1.2.1.bb and foo_1.2.3.bb, in the > same directory, then Bitbake always chooses 1.2.1 instead of the one > with the higher version number. Does bitbake always choose the first > matching version it can find? Is this a general limitation of wildcards, > or is this a problem that can get corrected? I'd expect it to choose the > highest matching version. If you want highest then why do you specify P_V at all? or are those 1.2% foo with e.g. negative D_P? or is there 1.3 you don't want? It will use first provider which matches (in highest usable prio/D_P group). sortpkg_pn = sortPriorities(pn, dataCache, pkg_pn) # Find the highest priority provider with a PREFERRED_VERSION set (preferred_ver, preferred_file) = findPreferredProvider(pn, cfgData, dataCache, sortpkg_pn, item) # Find the latest version of the highest priority provider (latest, latest_f) = findLatestProvider(pn, cfgData, dataCache, sortpkg_pn[0]) if preferred_file is None: preferred_file = latest_f preferred_ver = latest It was added mostly to cover use case with e.g. 1.2+svnr1337 or 1.2+gitrCAFEBABE where you don't care about exact revision, but you know that you want 1.2 from scm (and there is just one which matches). See this thread for details: http://lists.linuxtogo.org/pipermail/bitbake-devel/2009-September/000458.html Cheers, > > Regards, > Andreas > > _______________________________________________ > bitbake-devel mailing list > bitbake-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: PREFERRED_VERSION and wildcards 2012-03-14 22:54 ` Martin Jansa @ 2012-03-14 23:53 ` Andreas Oberritter 2012-03-15 0:02 ` Martin Jansa 0 siblings, 1 reply; 4+ messages in thread From: Andreas Oberritter @ 2012-03-14 23:53 UTC (permalink / raw) To: Martin Jansa; +Cc: bitbake-devel On 14.03.2012 23:54, Martin Jansa wrote: > On Wed, Mar 14, 2012 at 10:34:59PM +0100, Andreas Oberritter wrote: >> Hi, >> >> I just tried using wildcards, like it's done for gcc, e.g.: >> >> PREFERRED_VERSION_foo = "1.2%" >> >> Now, if I have two foo recipes, foo_1.2.1.bb and foo_1.2.3.bb, in the >> same directory, then Bitbake always chooses 1.2.1 instead of the one >> with the higher version number. Does bitbake always choose the first >> matching version it can find? Is this a general limitation of wildcards, >> or is this a problem that can get corrected? I'd expect it to choose the >> highest matching version. > > If you want highest then why do you specify P_V at all? or are those > 1.2% foo with e.g. negative D_P? or is there 1.3 you don't want? Yes, I'd like to prefer 1.2.x over higher versions, say 1.3.x, which coexist in the same directory, i.e. prefer stable over development versions. > It will use first provider which matches (in highest usable prio/D_P group). > > sortpkg_pn = sortPriorities(pn, dataCache, pkg_pn) > # Find the highest priority provider with a PREFERRED_VERSION set > (preferred_ver, preferred_file) = findPreferredProvider(pn, cfgData, dataCache, sortpkg_pn, item) > # Find the latest version of the highest priority provider > (latest, latest_f) = findLatestProvider(pn, cfgData, dataCache, sortpkg_pn[0]) > > if preferred_file is None: > preferred_file = latest_f > preferred_ver = latest > > It was added mostly to cover use case with e.g. 1.2+svnr1337 or 1.2+gitrCAFEBABE where > you don't care about exact revision, but you know that you want 1.2 from scm (and there > is just one which matches). I see. I must admit that I don't really understand how the code quoted above works. > See this thread for details: > http://lists.linuxtogo.org/pipermail/bitbake-devel/2009-September/000458.html OK, Now I understand the original intention, but its behaviour doesn't seem to be what you'd intuitively expect. Well, at least not what I'd expect. Would it be hard to extend the code to find the highest matching version instead of the first one? This wouldn't have negative effects on your use case. Regards, Andreas ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: PREFERRED_VERSION and wildcards 2012-03-14 23:53 ` Andreas Oberritter @ 2012-03-15 0:02 ` Martin Jansa 0 siblings, 0 replies; 4+ messages in thread From: Martin Jansa @ 2012-03-15 0:02 UTC (permalink / raw) To: Andreas Oberritter; +Cc: bitbake-devel [-- Attachment #1: Type: text/plain, Size: 2704 bytes --] On Thu, Mar 15, 2012 at 12:53:27AM +0100, Andreas Oberritter wrote: > On 14.03.2012 23:54, Martin Jansa wrote: > > On Wed, Mar 14, 2012 at 10:34:59PM +0100, Andreas Oberritter wrote: > >> Hi, > >> > >> I just tried using wildcards, like it's done for gcc, e.g.: > >> > >> PREFERRED_VERSION_foo = "1.2%" > >> > >> Now, if I have two foo recipes, foo_1.2.1.bb and foo_1.2.3.bb, in the > >> same directory, then Bitbake always chooses 1.2.1 instead of the one > >> with the higher version number. Does bitbake always choose the first > >> matching version it can find? Is this a general limitation of wildcards, > >> or is this a problem that can get corrected? I'd expect it to choose the > >> highest matching version. > > > > If you want highest then why do you specify P_V at all? or are those > > 1.2% foo with e.g. negative D_P? or is there 1.3 you don't want? > > Yes, I'd like to prefer 1.2.x over higher versions, say 1.3.x, which > coexist in the same directory, i.e. prefer stable over development versions. Ah, OK. > > It will use first provider which matches (in highest usable prio/D_P group). > > > > sortpkg_pn = sortPriorities(pn, dataCache, pkg_pn) > > # Find the highest priority provider with a PREFERRED_VERSION set > > (preferred_ver, preferred_file) = findPreferredProvider(pn, cfgData, dataCache, sortpkg_pn, item) > > # Find the latest version of the highest priority provider > > (latest, latest_f) = findLatestProvider(pn, cfgData, dataCache, sortpkg_pn[0]) > > > > if preferred_file is None: > > preferred_file = latest_f > > preferred_ver = latest > > > > It was added mostly to cover use case with e.g. 1.2+svnr1337 or 1.2+gitrCAFEBABE where > > you don't care about exact revision, but you know that you want 1.2 from scm (and there > > is just one which matches). > > I see. I must admit that I don't really understand how the code quoted > above works. > > > See this thread for details: > > http://lists.linuxtogo.org/pipermail/bitbake-devel/2009-September/000458.html > > OK, Now I understand the original intention, but its behaviour doesn't > seem to be what you'd intuitively expect. Well, at least not what I'd > expect. Would it be hard to extend the code to find the highest matching > version instead of the first one? This wouldn't have negative effects on > your use case. Agreed, but if someone starts working on it, then we should discuss first how to properly fix D_P across multiple layers, because I belive that it's also in those 5 quoted lines. Cheers, > > Regards, > Andreas -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-03-15 0:11 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-03-14 21:34 PREFERRED_VERSION and wildcards Andreas Oberritter 2012-03-14 22:54 ` Martin Jansa 2012-03-14 23:53 ` Andreas Oberritter 2012-03-15 0:02 ` Martin Jansa
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.