DMB Manage packagesets

Note

This page is about how to create and modify a packageset.

Related information about how to become an uploader of a packageset can be found at Packageset uploaders.

What is a packageset

Packagesets are a method to provide fine grained upload permissions without always managing everything individually per user. They define a set of package lists specified by Ubuntu release, which developers can gain upload permissions for.

Being per release allows them to evolve over time as Ubuntu changes, without such changes affecting the maintenance of existing releases. For example a package name might stay but contain something different in a later release. Or a definition by either of the Types of packagesets will imply that it covers a different set of packages in different releases.

In regard to their definition they exist are defined in the Launchpad database accessible by API (using the edit-acl command). Think of it as a relation between Launchpad personas and a list of packages.

        %% mermaid flowcharts documentation: https://mermaid.js.org/syntax/flowchart.html
flowchart TD
    %% Entities
    Developers["Developer"]
    LPPersona["Launchpad team controlled by the DMB"]
    PackageSet["Packageset in Launchpad database"]
    Packages["Source packages per release"]

    %% Transitions
    Developers -->|"<i>member of</i>"| LPPersona
    LPPersona -->|"<i>associated to</i>"| PackageSet
    Packages -->|"<i>in package list</i>"| PackageSet
    

For easy viewing, there are text files representing the current state of the packagesets. That includes the name of the sets, their description, the list of packages included as well as the developers allowed to upload to it. These files can be found at ~ubuntu-archive/packagesets.

Consider creating a packageset once we have:

• Two or more PPU uploaders with the same set.

• Two or more related packages that always belong together.

• The grouping of those packages needs to make logical sense.

The application process to Become a packageset uploader is similar to all other developer upload permission applications. In this case applying to a particular packageset instead of for example MOTU.

Types of packagesets

Historically there a few different kinds of packagesets. There are two common variants, one mostly reflect seeds and the other is logically defined by the description. Further variants that have been established to cover special cases like Personal packagesets and OEM metapackage packagesets.

• Logical packagesets needs a detailed description. This is so that developers can mail devel-permissions after the set is created in order to have packages added. A DMB member then needs to judge the description against the requested change and may apply the change if they decide it is warranted.

• Seeds based packagesets are instead defined by what is generally seeded and supported for a particular Ubuntu variant or has a direct relation to a seed named in the description. One has to be careful as there are exceptions that force a seed based packageset seeds to not be just equal to the seed. defies the purpose (See below about details on these cases).

  • These packagesets used to be fully generated based on this code and the logic tries to detect how sources are shared between flavours to remove those. But that has proven to cause too many exceptions. Therefore they have - for now - become defined by the seeds, but modified manually on request.

  • While currently not automated, the DMB still aims for eventual consistency. A seed based packageset should converge to be based on the seed, plus exceptions (agreed exceptions are currently tracked in DMB seed packagesets exceptions). Just like packagesets based on a logical definition converge on the text of their definition.

  • Common reasons for exceptions to a pure seed = packageset approach are:

    • Consider to remove a package from a set if is is in the related seed, but so central and impactful, that adding it would effectively make the packageset to require core-developer permission level. That would defy the purpose of being a stepping stone for upload permissions as on one could join until the could get core-developer rights anyway. Examples of that would be: grub2, systemd, or cloud-init.

    • Consider to remove a package from a set if it is also claimed by other seeds or common use case. In that case it often, but not always, is only updated by Ubuntu core-developers. Examples of that would be: vim, dhcpcd or tzdata

    • Consider to add a package to a set if it is not in the seeds, but such a common use case for the packageset that the same set of people that care about the rest is likely to also maintain these packages. Examples of that would be: docker.io or valkey

• Personal packagesets are used where an individual has a special reason for upload rights to a large number of packages that the DMB expects to need to manage frequently. For such a case a “personal packageset” for this person, named “personal-<lpid>” can be created.

  • When the associated developers are granted Core Dev those packagesets can be removed.

  • See the thread starting at May 2016, and subsequent months for an example.

• The canonical-oem-metapackages packageset is glob based. The exact glob is defined in the packageset description and is expanded according to the list of source packages in the Ubuntu Archive for a given series. Any DMB member may update the packageset according to the glob expansion at any time without needing further consultation. However, this is now done automatically with this script. The script is “owned” by the DMB, who is the gatekeeper for changes to the script, but run and managed on behalf of the DMB by the Archive Admin team. To make this work, this packageset is owned by the Archive Admin team.

  • The expected nature of the packageset, to which the DMB grants upload access, relies on the MIR team’s requirements for these packages, defined at MIR exception - OEM packages.

  • Background thread

  • Decided at the DMB meeting of 2020-08-11

  • Documented at OEM Archive

How to modify a packageset

One can modify the definition, the members or the associated package list.

This is the more common task compared to creating a set.

How to modify a packageset definition

• If necessary, we can modify the description later on following a full DMB vote. Such requests would usually be driven by members of a packageset that want to expand the set or better define it - often to match how Ubuntu has evolved since the set was created. In such a case the DMB should consider if, due to the update of the definition, it would need to reconsider:

  • the set of packages in the packageset, and if they should be adjusted

  • the set of uploaders to the packageset, and if they should be adjusted.

How to modify members of a packageset

• Modification of the membership list for an existing packageset team can be done directly by the DMB. A DMB member should go to the packageset uploader team page, and add (or if needed remove) the applicant to the team.

  • If not already a member, add the applicant to either ~ubuntu-dev or ~ubuntu-uploaders. See Teams to add uploaders to.

How to modify a new packageset list of covered packages

• Modification of the package list for an existing packageset can also be done directly by the DMB. This requires using the tool edit-acl.

  • Example: (replace add with delete to remove a package instead of adding):

    edit-acl -S $RELEASE -P $PACKAGESET -s $PACKAGE add
    

  • Sometimes a package or use case is new, but sometimes it is valid for all releases, in that case the command should be repeated for all supported releases:

    for RELEASE in $(distro-info --supported); do edit-acl ...; done
    

How to create a new packageset

This step is comprised of creating the packageset team managed by the DMB as well as creation of the packageset associated with it.

More often than creating one would modify an existing package set.

Create the associated Launchpad team

We create initially packagesets with just one uploader, which is a Launchpad team that we then later add developers to.

1. Start at new team registration page.

2. Make the description to match what was proposed and approved by the DMB

3. Make sure Membership Policy is Restricted Team.

4. Set both the Subscription Period and Self Renewal Period to 720 (or 180 for ‘flavor’ teams).

5. Change renewal option to invite them to renew their own membership.

6. Create the team.

7. On the new team page:

   1. Click Change Details and then Change Owner.

   2. Change the team owner to developer-membership-board.

8. On the new team member page:

   1. Add ubuntu-core-dev.

   2. Edit ubuntu-core-dev membership expiration to Subscription Expires: Never.

   3. Remove (deactivate) yourself.

   4. Remove (deactivate) developer-membership-board (membership, keep ownership).

9. Go to ~ubuntu-uploaders member page and add the new team as a member. (In rare cases the DMB may require membership of packageset uploaders, in that case add it to ~ubuntu-dev member page instead)

Create the actual packageset

• If the action requires creation of a new packageset or PPU, or (rarely) changes to the uploader for a packageset or PPU, it must be done by the TB, so the DMB member must:

  1. For a new packageset, create a new uploader team (see What is a packageset section)

     • For a new PPU, the uploader is the applicant

  2. Open a bug against the ubuntu-community project, and the bug description should include the exact edit-acl command to run.

     • For PPU creation, file a bug with this subject and include the PPU member name

     • For packageset creation (or uploader team change), file a bug with this subject and include the packageset name

     • In the bug, if creating a new packageset, request the TB create the packageset, setting the DMB as owner:

       edit-acl -S $RELEASE -p developer-membership-board -P $PACKAGESET -t admin create
       

     • Also request the TB set or change the uploader:

       edit-acl -S $RELEASE -p $UPLOADER -P $PACKAGESET -t upload modify
       

     • Usually the commands should be repeated for all supported releases:

       for RELEASE in $(distro-info --supported); do edit-acl ...; done