Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
apk-tools
apk-tools
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 60
    • Issues 60
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 13
    • Merge Requests 13
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • alpine
  • apk-toolsapk-tools
  • Merge Requests
  • !1

Open
Opened Nov 08, 2019 by Fredrik Gustafsson@fredrigu
  • Report abuse
Report abuse

Check out, review, and merge locally

Step 1. Fetch and check out the branch for this merge request

git fetch "https://gitlab.alpinelinux.org/fredrigu/apk-tools.git" "multiarch"
git checkout -b "fredrigu/apk-tools-multiarch" FETCH_HEAD

Step 2. Review the changes locally

Step 3. Merge the branch and fix any conflicts that come up

git fetch origin
git checkout "master"
git merge --no-ff "fredrigu/apk-tools-multiarch"

Step 4. Push the result of the merge to GitLab

git push origin "master"

Note that pushing to GitLab requires write access to this repository.

Tip: You can also checkout merge requests locally by following these guidelines.

Add multi arch support

  • Overview 21
  • Commits 2
  • Changes 13
Add multi arch support

Architectures are not either A or B but are more like a tree in
relation. That is one architecture can contain an other. An easy
example here is a package with only shell scripts that should
have the architecture 'none', 'all' or something like that while
a binary package might have 'amd64'. In this example apk should
be able to install packages from both 'none' and 'amd64'
architectures.

Today apk only support one architecture and has an option for
rewriting the architecture upon creating a repo index
( --rewrite-arch ARCH  ). This change makes it possible to have
one repository for each architecture and then mix different
architectures in the same installation.

This means:
* /etc/apk/arch can no contain a list of architectures supported.
* the --arch argument can be specified multiple times to add new
  architectures to /etc/apk/arch

This will make it possible for architectures to share common
repository, which will ease maintenance of different architectures
as well as improve storage requirements for hosting repos. It will
also make it easier to use apk in yocto.

The downside is that apk needs to look at at most, number of
architectures, places for a package.

index: add argument --no-warn-if-no-providers

When creating an index apk warns if a dependency is missing a provider.
However when using a multi-arch repository, it's not an error that
a certain architecture is missing a dependency because that dependency
could be in an other architecture. Since apk index doesn't know about
this, add an argument to disable that warning.
Edited Apr 28, 2020 by Fredrik Gustafsson
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
0
Labels
None
Assign labels
  • View project labels
Reference: alpine/apk-tools!1
Source branch: multiarch