I’d suggest you stop doing those painful big bang migrations and rather transition to ‘master plus stable backports’ model.
Alex On Thu 7. Nov 2024 at 17.31, Logan Grosz via lists.yoctoproject.org <Logan.Grosz=b9c....@lists.yoctoproject.org> wrote: > Alex and Chuck, > > Thank you for your timely responses. > > Nobody ever promised you can use the same layer with more than one yocto > release. Please make a branch. > > I am aware, but I am also aware of LAYERSERIES_COMPAT > <https://docs.yoctoproject.org/bitbake/2.10/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-LAYERSERIES_COMPAT>. > I > am hoping to utilize it for a brief period to keep our git tree functional > on every commit. > > Is there something unique and special about your particular factory reset > target? If not, I suspect > what you are experiencing is a sign that it is time to get rid of that > recipe. > > No, there is nothing special about the target. The plan is to remove the > target when we are completely migrated over. > > If you are using that same layer to build images for multiple Yocto > release versions, this problem is > only going to get worse. Recipe compatibility is not guaranteed between > discrete Yocto releases. > The expectation is that you will branch and update your recipes to keep > pace with each release you > want to support. > > There are *a lot* of changes we are making, so I was trying to keep the > changeset to a minimum. In an effort to keep a nice bitsect-able Git > history, I'm trying to keep the layer buildable on both Yocto releases. > However, I plan on removing any extra handling for the old version once we > have a nice workable build on this newer version. > > I only bring this up because it's not uncommon for software to check a > version of its dependency to support multiple versions of it at build-time. > I figured this was a very similar concept. > > If there's no neat way of doing this solely in the recipe, then I'll apply > the patch early and note it breaks the factory-reset feature until SystemD > 250. > Thank you, > Logan > ------------------------------ > *From:* Chuck Wolber <chuckwol...@gmail.com> > *Sent:* Thursday, November 7, 2024 9:02 AM > *To:* yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org>; Logan > Grosz <logan.gr...@b9c.com> > *Subject:* Re: [yocto] Conditionally set SYSTEMD_SERVICE_${PN} based on > version of another package > > On Thu, Nov 7, 2024 at 7:34 AM Logan Grosz via lists.yoctoproject.org > <Logan.Grosz=b9c....@lists.yoctoproject.org> wrote: > > Hi, all > > My company is trying to migrate a newer version of Yocto and in an effort > to do that I am making changes to our current layer to facilitate an easier > transition. One problem I encountered was SystemD 250 installs a target > factory-reset.target, but we already have a recipe that installs a that > same file. The recipe is as follows > > > Is there something unique and special about your particular factory reset > target? If not, I suspect > what you are experiencing is a sign that it is time to get rid of that > recipe. > > If you are using that same layer to build images for multiple Yocto > release versions, this problem is > only going to get worse. Recipe compatibility is not guaranteed between > discrete Yocto releases. > The expectation is that you will branch and update your recipes to keep > pace with each release you > want to support. > > ..Ch:W.. > > *"Perfection must be reached by degrees; she requires the slow hand of > time." - Voltaire* > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#64236): https://lists.yoctoproject.org/g/yocto/message/64236 Mute This Topic: https://lists.yoctoproject.org/mt/109446043/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
