Aports what is edge

From Alpine Linux
Revision as of 01:34, 27 June 2022 by Encode (talk | contribs) (This should be covered in Repositories now)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
This material is proposed for deletion ...

This should be covered in: https://wiki.alpinelinux.org/wiki/Repositories (Discuss)
Make sure no other pages link here and check the page's history before deleting.

What is edge (The Definition)

Short definition
Edge is a rolling release branch.

[Illustration]

  • bleeding edge
  • tree on the cliff

How packages move in edge (The Juggler)

What are repositories (main|community|testing) ? See, https://wiki.alpinelinux.org/wiki/Aports_tree

  1. MAIN
    1. Main has a support cycle of 2 years
    2. Support the main repository for 1.5 year (a total of 2 years)
    3. We also try to limit the amount of packages in main to only include base system packages, in base you can think of packages which are needed by other packages or are needed to setup a basic system.
    4. Packages in main must not have dependencies in other repositories.
  2. COMMUNITY
    1. Community has a maximum support cycle of 6 months.
    2. Support will stop (you will need to upgrade to the new release to continue to have support)
    3. Packages limited if its a bloat
  3. TESTING
    1. No support (staging only), only built for edge.
    2. If it stays here long enough it gets moved to unmaintained/purged (gets cleaned up every 6 months)
    3. No limit
  4. UNMAINTAINED
    1. Unmaintained packages are not build.
  5. NON-FREE
    1. Don't ask, don't tell, we only like opensource.

[Illustration]

  • bananas for repos (green=testing, green/yellow=community, yellow=main)
  • unmaintained(brown), algibot with closed nose, brooming it away
  • non-free(transparent), we act as if they do not exist

Before a package can move from testing to main or community, the following requirements must be met:

  1. Package must work correctly, including the init.d script (if provided) and default configuration
  2. Packaging must be done correctly, with files installed in the right places, e.g. configs are in /etc/ and not in /usr/etc
  3. Package dependencies are handled correctly. Abuild can (and should) autodetect shared libs, for example sqlite-libs provides so:libsqlite3.so.0, any package linked to sqlite should have an automatically (by abuild) added depend=so:libsqlite3.so.0 and user should not manually add a depend="sqlite-libs" in the APKBUILD
  4. There is a maintainer who claims responsibility for the maintenance of the package and can help fixing things if they break in the future

Packages that go to next stable release (The Reap)

Every new stable release will be a branch created from our master branch (our current edge release). The only two repositories included in stable branches are main and community. This means any package that is currently in our testing repository will not be included in our new release. This is because testing is a kind of staging directory where we test packaging before we move them to one of the two other repositories (most probably community).

Please also keep in mind that our community repository is still young so many packages will still need to be moved to community, we try to do that when we bump into them.

[Illustration]

  • Hoga-boga dance around fire
  • Harvesting season


What is stable release (Fruits of Labor)

- How to find latest stable release?

[Illustration]

  • Vacation to alpine wilderness


Do we backport new packages(from edge) to previous stable releases (The Gift, Favor)

  1. Make a request on forum/irc, mailing list or add to bugs.a.o and wait.
  2. Don't forget to say why (in short).
  3. Be prepared for rejection.

[Illustration]

  • Algibot controlled drone dropping packages (the gift).


How packages are deleted (The Purge)

Presently applies mostly to "testing".

Checks before purge

  1. If packages is feature complete
  2. If its stable and no equivalent package is available
  3. If its a hard-depends for another package.
  4. If its requiring extra maintenance then move to a lower priority level
  5. If its a problem, add to bugs.alpinelinux.org first, once bugs get comments, vote or veto
  6. If its in 'testing' long enough (this is shaky)

After purge

  1. Remember to replace with equivalent packages if its only of a kind
  2. Notify in "detailed changes list" in release notes (applies to main|community)

[Illustration]

  • Algibot shooting packages with nose clips on
  • Algibot brooming it away


Glossary

  1. Support - mostly security fixes and major software issues
  2. Special packages - packages voted to be special (not otherwise as understood as basic system package)

See Also