> Stability means: no changes in functionality. Ah, this is the key point of my proposal. Stability for my purposes means predictability when changes in functionality will occur.
> 4. Apt is geared towards advancement, not retreat. Meta packages can't be > used to uninstall, and rarely to downgrade. Any component grouping would > benefit from being real atomic entities that can be removed as a whole as > well. > > 5. My main point is that components could introduce new apt jargon in the > sense that: > > "apt groups" would list all components > "apt list <group>" would list the packages for that component > other apt commands remain the same, but might have slightly different > operation. I did consider that parts of this proposal might be easier in snaps, which would be a bit more like you describe. I tried to limit to items that we could test for a 6 month period of time. > Additionally with respect to point 4, I think it is essential that people > can also downgrade to a previous 'Monthly'. > > This means that all the library versions of that monthly still have to be > available in the repos essentially creating 'frozen' sets for each month. > > Also, if meta packages (or new "groups") pull in the upgrades they must be > specified on exact versions so that pervious meta packages can downgrade > what was upgraded. > > Ie. the meta package "monthly-latest" pulls in "monthly-18.10.4", with > "monthly-18.10.4" pulling in the changes, but "monthly-18.10.3" would be > able to undo all of that. > > This would imply that those monthly metas do not only indicate what they > upgrade, but also what they didn't upgrade. > > The monthly metas then indicate the exact versions of all core components. Then we have monthly releases, I specifically didn't want to do that. Obviously it's something that could be considered instead though. > As an additional colloquium: > > Core components might also need to specify ALL libraries being pulled in > by their upgrade, and might require those libraries to be split off into > components of their own if these libraries are shared between core > components. > > At the same time this creates inflexibility; you cannot keep using an > older version of udev if it breaks some device. > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
