All of lore.kernel.org
 help / color / mirror / Atom feed
* Design - Editing package content in custom images
@ 2015-08-07 13:11 Barros Pena, Belen
  2015-08-11  8:28 ` Reyna, David
  0 siblings, 1 reply; 3+ messages in thread
From: Barros Pena, Belen @ 2015-08-07 13:11 UTC (permalink / raw)
  To: toaster

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




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Design - Editing package content in custom images
  2015-08-07 13:11 Design - Editing package content in custom images Barros Pena, Belen
@ 2015-08-11  8:28 ` Reyna, David
  2015-08-11 10:28   ` Barros Pena, Belen
  0 siblings, 1 reply; 3+ messages in thread
From: Reyna, David @ 2015-08-11  8:28 UTC (permalink / raw)
  To: BARROS PENA, BELEN, toaster

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, and/or one with the "removed" packages keep magically re-appearing in the final image.

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.
  * 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.
  * The forth method is to have an actual "Undo" button, but this would be a lot of work.

- 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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Design - Editing package content in custom images
  2015-08-11  8:28 ` Reyna, David
@ 2015-08-11 10:28   ` Barros Pena, Belen
  0 siblings, 0 replies; 3+ messages in thread
From: Barros Pena, Belen @ 2015-08-11 10:28 UTC (permalink / raw)
  To: Reyna, David L (Wind River), toaster



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



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-08-11 10:28 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-07 13:11 Design - Editing package content in custom images Barros Pena, Belen
2015-08-11  8:28 ` Reyna, David
2015-08-11 10:28   ` Barros Pena, Belen

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.