Ethan Quach wrote: > > > Jan Damborsky wrote: >> Hi Ethan, >> >> >> Ethan Quach wrote: >> >>> >>> It doesn't seem to solve the problem for when an older build is wanted. >>> i.e. you can't image-update backwards. >> >> That is correct. So if I understand correctly, the requirement is to >> support >> both installation of older IPS bits as well as newer IPS bits >> comparing to >> the ones AI image was created from ? What is the need to support >> installation >> of older bits ? > > The same need as for supporting the installation of newer bits. > What is it about installing newer bits that makes it more of a > desired use case than the corollary?
I think those use cases are not quite equal. This comes from IPS repository versioning scheme - it is unidirectional - when anything is pushed into IPS repo, version is always changed to newer, never to older one. Speaking about particular use case, let's assume that at some point user has AI image which allows installation of IPS bits currently available in given IPS repos. When time runs, it is likely that newer bits will be made available, it can't happen that older bits occur in IPS repo. So only X+1 versioning problem will occur. I am not sure, how common is going to be comparing to the others when X-1 problem would have to be solved, just trying to think where the differences come from and how those map to the possible use cases. > > The general case I thought we are trying to solve is that if > there is no technical reason why bld X should fail to install > X-1 or X+1, why should it not be supported, or why should > we prevent that? I think those two cases are not symmetric with respect to the limitations of technologies AI consumes: * IPS supports only upgrade * ZFS pool allows only upgrade I am not sure if there are any technical limitations for them (there might be), but at least we need to take them into account when thinking what is involved in support of X-1. > >> >>> >>> In general, using IPS's pkg ideology to ensure the contents of the >>> IMAGE >>> is intact is a good idea. So moving any and all, if possible, of our >>> ICTs >>> into pkg contents is what we are driving towards. But their are >>> structural >>> pieces outside of the IMAGE -- disk, zpool, grub, etc -- that pkg >>> doesn't >>> touch and we still need to consider those in the CVERS problem. >> >> I am currently aware of need to manually run 'zpool upgrade' in order >> to 'upgrade' ZFS pool to the latest version, do we happen to know if >> there are >> other incompatibilities pkg 'image-update' currently doesn't take >> care of and >> how they are handled ? > > The one we know of is updating grub on the disk. We currently > handle this be pushing that responsibility to the be_activate() > code. Is it something which has to be handled by Snap Upgrade or can it be addressed by IPS ? I am asking trying to understand what the pieces are installer really has to take care of and what can be solved by other mechanisms/projects. Thank you, Jan
