Re: Design - Editing package content in custom images

["Barros Pena, Belen" <belen.barros.pena@intel.com>]

On 11/08/2015 09:28, "Reyna, David" <david.reyna@windriver.com> wrote:

>Hi Belén,
>
>The design is great.
>
>The fundamental gotcha as I mentioned before is that the users will find
>that if they go too far deleting packages then (due to the imperfect
>nature of the package dependencies) they will eventually end up with an
>image that is unbuildable,

Well, the image will probably build, although it might not boot. Still, I
agree that wouldn't be a great outcome ;) But without creating limitations
that do not currently exist in the build system I am not sure how we can
avoid this. Instead of having the "all flexible, all powerful" approach of
the Yocto Project, we would need to establish a minimum set of packages
that all images should have, and make those non-removable. I would not
necessarily disagree with this approach for a specific product version of
Toaster, but for the Yocto Project generic version it makes me a bit
nervous. I wouldn't like to be the one trying to sell the idea to the
maintainers ;)

>and/or one with the "removed" packages keep magically re-appearing in the
>final image.

Well, I guess this will happen based on the packages you add. We do have
some information about dependencies, and we do show it to users before
they add a package. The build history will then give you an accurate
picture of what actually happened during a build. Beyond this, I am not
sure there is much else we can do.

>
>I think that we should prepare for that. We should at least have a
>disclaimer that package deletion can sometimes lead to unsupported or
>surprising states. We should consider/advise some sort of recovery
>method, for example.
>
>  * The simplest undo is to delete the broken image and start fresh. This
>may be sufficient for this initial release.
>  * The second simplest is to have a "reset", where you re-start this
>image from its baseline source.

I quite like this idea of a 'reset' option. It would require knowing what
was in the base image. Ed, Michael, Alex: do we know this? What would it
take to know? I don't care much if "what was in the image means"

1. the list of packages that were installed by the base image when you
created the custom image, or
2. the list of packages installed by the upstream version of the base
image (which means there could be some differences between the original
package list and the one we can restore)

In practice, any of the 2 would be useful.

>  * The third option is to mark the removed packages in a way that
>indicates that they were originally part of the baseline, for example by
>having them use a "Re-add package" button label as opposed to "Add
>Package". In this manner they have a clue on how to "undo" the changes
>visually.

Again, this would require remembering what was in the base image somehow,
so we need an answer to the question above. From a design perspective, it
means 3 types of buttons, which can add a bit of noise. But we could
definitely try it and see.

>  * The forth method is to have an actual "Undo" button, but this would
>be a lot of work.

We have been talking about adding this. So when it is in place, we should
definitely use it in the package addition / removal context.

Cheers

Belén

>
>- David
>
>
>> -----Original Message-----
>> From: toaster-bounces@yoctoproject.org [mailto:toaster-
>> bounces@yoctoproject.org] On Behalf Of Barros Pena, Belen
>> Sent: Friday, August 07, 2015 6:12 AM
>> To: toaster@yoctoproject.org
>> Subject: [Toaster] Design - Editing package content in custom images
>>
>> I've documented how we add and remove packages to / from custom images,
>> and opened this enhancement
>>
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=8117
>>
>> Design attached to the Bugzilla entry, as usual. The only tricky thing
>>is
>> the dependency handling, but we used to this in Hob, so I am assuming we
>> can do this in Toaster as well.
>>
>> Any questions / comments, let me know.
>>
>> Thanks,
>>
>> Belén
>>
>>
>> --
>> _______________________________________________
>> toaster mailing list
>> toaster@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/toaster