You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a condensed form of a more detailed proposal on this topic. Please contact @kevincwells for information.
Current State/Motivation
Currently, the way you add bundles to your mix is to copy the bundle definition file from a given version of CLR into the mix-bundles directory. That means the existence of bundle definition files in your mix-bundles directory is the specification of what bundles you want to include in your mix. Meanwhile, the mix-bundles directory is, in fact, input to other tools (bundle-chroot-builder.py).
This causes ambiguity and problems, especially when handling bundles that include other bundles. For example let’s say the developer cares about including Bundle_A in their mix, and that bundle itself includes Bundle_B. That means mix-bundles will contain both Bundle_A and Bundle_B, but there is no way to know that Bundle_B is only there as an include. So later, if Bundle_A gets modified upstream to no longer have that include, the developer is “stuck” with Bundle_B, because it is in their mix-bundles directory, and we cannot tell the difference.
Proposal
Allow the user to include some bundles as-is from upstream (CLR) without maintaining a local copy.
Change how to specify what bundles are included in a mix to be a Mix Bundles List containing all the bundles that must be in the mix. Other bundles will be automatically added by Mixer to fulfill bundle includes.
Create a local-bundles directory to contain user-created and edited bundles.
Think of this as analogous to the local-rpms directory.
Any bundles in the Mix Bundles List that are not in the local-bundles directory are treated as "Upstream Bundles" and are included from upstream (CLR) as-is.
Populate the mix-bundles directory (the input to bundle-chroot-builder) on the fly when chroots are built. Bundles included by other bundles are handled automatically, and local bundles always take precedence over their upstream counterparts.
The text was updated successfully, but these errors were encountered:
Minor: would change "Change the specification of what bundles are included in a mix to be a Mix Bundles List containing only top-level bundles (i.e., not those that are included)"
to something like:
"Change how to specify what bundles are included in a mix to be a Mix Bundles List containing all the bundles that must be in the mix. Other bundles will be automatically added by Mixer to fulfill bundle includes."
with the intent of clarifying what bundles are guaranteed to be part of the mix (those listed).
Note
This is a condensed form of a more detailed proposal on this topic. Please contact @kevincwells for information.
Current State/Motivation
Currently, the way you add bundles to your mix is to copy the bundle definition file from a given version of CLR into the
mix-bundles
directory. That means the existence of bundle definition files in your mix-bundles directory is the specification of what bundles you want to include in your mix. Meanwhile, the mix-bundles directory is, in fact, input to other tools (bundle-chroot-builder.py
).This causes ambiguity and problems, especially when handling bundles that include other bundles. For example let’s say the developer cares about including Bundle_A in their mix, and that bundle itself includes Bundle_B. That means
mix-bundles
will contain both Bundle_A and Bundle_B, but there is no way to know that Bundle_B is only there as an include. So later, if Bundle_A gets modified upstream to no longer have that include, the developer is “stuck” with Bundle_B, because it is in theirmix-bundles
directory, and we cannot tell the difference.Proposal
Allow the user to include some bundles as-is from upstream (CLR) without maintaining a local copy.
local-bundles
directory to contain user-created and edited bundles.local-rpms
directory.local-bundles
directory are treated as "Upstream Bundles" and are included from upstream (CLR) as-is.mix-bundles
directory (the input tobundle-chroot-builder
) on the fly when chroots are built. Bundles included by other bundles are handled automatically, and local bundles always take precedence over their upstream counterparts.The text was updated successfully, but these errors were encountered: