| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
|
| |
|
|
|
| |
The daemons file will be generated during the build, so there is no
need to copy it over from the first stage.
|
| |
|
|
|
|
|
|
|
| |
We need libyang to build FRR, so add it to the make dependencies.
Alpine will automatically detect it as runtime dependency, so no
need to add it there.
The package binutils-libs doesn't exist anymore, so remove it from
the dependencies.
|
| |
|
|
|
|
| |
The standard Alpine package should not install docker glue,
so remove it from the APKBUILD and install it in the Dockerfile
instead.
|
| |
|
|
|
|
|
| |
There's a few left over to get compatibility and not break user
installs, but most is gone.
Signed-off-by: David Lamparter <equinox@diac24.net>
|
| |
|
|
|
|
|
|
|
|
| |
Now that make check works on alpine, add it to the build
Testing done: alpine linux build -- check works
Issue: https://github.com/FRRouting/frr/issues/2391
Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, we just package the frr daemons, but we don't run
them. This is fine for basic tests, but it is inconvenient to
orchestrate the daemons from downstream test environments.
Here, we follow the redhat and debianpkg formats more closely,
putting the daemons in /usr/lib/frr and including the frr user
and groups in the package. We also include a docker specific
startup script and a sysvinit link in /etc/init.d/frr for
openrc based alpine installs.
Testing done:
Built packages, built base images, everything seems to work fine.
Uninstalled the package, all the daemons stopped.
Issue: https://github.com/FRRouting/frr/issues/2030
Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
|
| |
|
|
| |
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Building alpine packages in a "standard" distro can be
complicated due to the limited scope of the distro (embedded
and small docker images). Building in a VM is one possibility,
but docker support for alpine is very good (default docker images
come in alpine due to the very small size).
Here, we want to package up the current git repo into apk packages
that can be easily installed in alpine linux using the apk tool.
This support is not intended to package released versions of
apk packages, that, if it comes to be, should be done here:
git://git.alpinelinux.org/aports
We're content here to build packages that can be used by developers
to try out frr in docker and other alpine environments.
This is a very minimal environment, we don't support importing
keys (so, installing the packages with apk requires the
--allow-untrusted option). In addition, we can't use the
git commit id in hex as version tag, as alpine doesn't support hex
digits in the version string. So, we need to convert the git hash
to decimal before tagging the package with the extra version.
This is yucky, but I can't think of another way to get a
unique version per package. The alpine way (using a numeric date),
only works for released packages, not for dev packages.
Issue: https://github.com/FRRouting/frr/issues/1859
Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
|
|
|
For building dev packages for alpine, we provide a minimal APKBUILD
file and add a configure option for only numeric versions in the
VERSION variable as alpine does not allow non-numeric characters
in the version string.
These changes allow alpine to be built, but don't yet provide a
mechanism to build. Changes to do the build in docker are coming
soon...
Testing done:
Built alpine packages in local docker environment, packages
showed no "dev" in the package name. Also built CentOS packages
with numeric version disabled and the "dev" is still in the package
name.
Issue: https://github.com/FRRouting/frr/issues/1859
Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
|
