copy /etc/lsb-release into the DLC module and keep it there. |
||
Issue descriptionAdding the APPIDs to the manifest and putting the manifest inside the DLC itself simplifies the paygen. I allows to do: cros_generate_update_payload --image dlc_image --output payload.bin And that's it. We don't have to pass the appids to the update_engine or image loader, but for paygen it is much easier to do this. for the platform updates, we can mount the image and catch the /etc/lsb-release out, but there is no way to do this in for DLCs.
,
Dec 7
i don't quite get it... what problem this is trying to solve? isn't DLC app id depending on the platform app id?
,
Dec 7
True, but how to get the platform APPID just from the DLC itself? We need a way to do that. right?
,
Dec 7
DLC payload itself should not exist without platform payload (or to rephrase it - they are generated together always), right? the manifest is settled at build time while the appid is dynamic - a DLC (and its manifest) may be on beta channel and promoted to stable later.
,
Dec 7
> DLC payload itself should not exist without platform payload (or to rephrase it - they are generated together always), right? The way paygen works is it is given a set of partitions and it will generate payloads for them. That is true that they get generated together with the platform image, but then we have to increase the coupling in the paygen by keeping the cache of 'which platform image belongs to a particular DLC' which can easily be avoided by this. This way we can just generate payloads from a DLC without worrying about what image or build it belongs too. > the manifest is settled at build time while the appid is dynamic - a DLC (and its manifest) may be on beta channel and promoted to stable later. at paygen we are not in the install time yet. If you look at /etc/lsb-release you can see all three APPIDs. At the runtime the correct APPID will be chosen dynamically based on which channel we are etc. So basically we keep all the available APPIDs and choose the correct one at runtime if needed.
,
Dec 7
i assume this "manifest json" is the one mentioned in go/dlc-spec, then no since appid only exists in /etc/lsb-release. but if "manifest json" means some other manifest files, i strongly suggest a proper design doc. so far i don't see any design decisions at this complexity level being made successful over crbug.com.
,
Dec 7
yes, manifest json in go/dlc-spec, why not? Any particular reason you're concerned with? Another option is just copying the /etc/lsb-release in the DLC too :) But I'm not really sure how often the lsb-release changes during the build time. Probably we don't care even if it changes, we just need the APPIDs. These are not very complicated decisions and having these on the bug is traceable and addressable. Think about them as a simple feature that we want to add this is kind of a feature request :)
,
Dec 7
after reading the entire thread again, i realized you meant to put 3 appids into the DLC manifest json. before discussing any alternatives. i was curious why "not having appid in DLC manifest" blocks you? also i want to remind you that manifest.json is in rootfs together with /etc/lsb-release. why duplicating appids in two places?
,
Dec 7
> also i want to remind you that manifest.json is in rootfs together with /etc/lsb-release. why duplicating appids in two places? I'm very aware of that :) Thanks. To answer your questions on #8: I give you a DLC image. Create a payload and its accompanied json file for it so the nebraska can process it. How do you do it?
,
Dec 7
hey Amin, can you please write a design proposal to describe what the problem exactly is and your end-to-end solution? i can't make a decision based on info i get so far on this thread...
,
Dec 7
Talked offline, The conclusion is that it is very beneficial to copy the /etc/lsb-release in the DLC module so given a DLC we would know what board it belongs too, and other information that was not originally available.
,
Dec 7
sounds good to add "metadata" into the DLC image itself.
,
Dec 8
,
Dec 8
This should probably go in dlc.eclass right? Does /etc/lsb-release exist during the build packages stage?
,
Dec 8
comment #14: it's in build_image I think. http://cs/chromeos_public/src/scripts/build_library/base_image_util.sh?rcl=639a155b78ef2c44980d54d130d7defe180a4b6e&l=296
,
Dec 9
Hm, I think it's less than ideal to only partially create a DLC when it is emerged. We should be able to run `emerge my-dlc` and get something that can be packaged into a payload and installed to a device without relying on a hook in build_image (or manual intervention) to grab lsb-release once it's generated.
,
Dec 9
Yeah, I thought about that problem too. But eventually the lsb-release will be available at some point. So, we might end up having two stages in the build_dlc (like call it two times depending on whether we have the lsb-release or not). Or we can create our own lsb-release based on whatever information we have at that point.
,
Dec 10
Any idea when the platform appids become available? That's really all we _need_ right? I image we should have it at some point in build_packages.
,
Dec 10
|
||
►
Sign in to add a comment |
||
Comment 1 by ahass...@chromium.org
, Dec 7