1) KDE RE releases x.y.z source packages to kde packagers.
2) Someone in KF commits the latest copy of the KDE ports from
the FreeBSD tree to the area51 module.
3) Someone in KF grabs the source packages from ktown.kde.org and
puts them in KF private workspace.
4) An initial ports upgrade is worked out.
5) Ananas is prepped for an initial run.
6) Compile-time or ports bug fixes made.
7) Go to step 5 and repeat as necessary.
8) Announce packages for testing purposes.
9) Runtime bug fixes made, go to step 5 and repeat as necessary.
10) Final packages are posted to ktown for release.
11) KDE releases x.y.z.
12) Final diff is made between original FreeBSD versions and the
versions at the end of step 10.
13) Diff is committed to FreeBSD repo.
1) KDE RE releases x.y.z source packages to kde-packagers list.
People who are currently on kde-packagers list:
Will, Andy, Lauri
You don't need to be on the list to know the tarballs are there,
since KDE people will see the tagging being done, but we can
probably have more people added if we find it necessary.
The packagers list is used mainly for three things:
a) Announce tarballs
b) Announce updated tarballs
c) whine about serious build problems that we can't fix ourselves
that might require updated tarballs
2) Someone in KF commits the latest copy of the KDE ports from the
FreeBSD tree to the area51 module.
We should be able to keep this in sync anyway, with 'many eyes'
watching the main FreeBSD repository and catching any commits made
by people outside the main team (such as when portmgr goes through
and does mass changes, or when someone updates a dependency and
updates our Makefile to account for it.)
In any case, we need to make sure we *are* working from the latest
base, so this is something we should actually do before step 1,
when we know that a KDE release is due very soon.
3) Someone in KF grabs the source packages from ktown.kde.org and puts
them in KF private workspace.
a) on Rabarber the distfiles go into:
/net/rabarber/data/distfiles/KDE/
b) People with access to the account on ktown:
Currently Will, Andy, Lauri (Adriaan?)
c) You can fetch directly to vattenmelon from ktown, to save home
bandwidth. You're welcome to grab a copy of the tarballs to work
with, but they are not yet for distribution, so there should not be
any public access at this point.
4) An initial ports upgrade is worked out.
Steps to do the initial port upgrade:
a) Update the version in Mk/bsd.kde.mk (and commit it to area51)
This will automatically change the version for all KDE ports
EXCEPT the handful of i18n ports with specified versions in
their own Makefile
b) Update the checksums.
With the distfiles in /usr/ports/distfiles/KDE (and i18n ports
in /usr/ports/distfiles/KDE/i18n) and an updated Mk/bsd.kde.mk, you
can go into each port directory and do 'make makesum' - this wll
update the distinfo file, which you can then commit directly to
area51.
If you want to do them by hand (say, on vattenmelon, because you
haven't downloaded the tarballs locally) it's just a normal md5
sum, you can look at the existing distinfo to see the format, or
here's an example:
MD5 (KDE/kde-i18n/kde-i18n-af-3.1.tar.bz2) = e976ec69f804dad6758115c3c0c34de7
c) Check for i18n ports changes. There are three scenarios:
Ports that were supplied with the last upgrade, but not with
this one: Change the
PORTVERSION= ${KDE_VERSION}
in their Makefile to the specific version.
Ports that were not supplied with the last upgrade, but are
supplied with this one: Change the
PORTVERSION= M.m.n
in their Makefile to
PORTVERSION= ${KDE_VERSION}
Ports that weren't supplied with the last version or this one:
They are probably ok just as they are, but do check that the
tarball they are trying to fetch is still available (that is,
does make fetch work for them.) If it's not, we should mark
them BROKEN, but not remove them, unless we know there's no hope
that they will ever be updated again.
d) Check for changed dependencies.
Do a common sense check that anything listed in libdepends and
builddepends in the Makefile for each port is still required.
Check that any known hard dependencies are covered
(non-optional build time dependencies)
Check that any other build-time dependencies are covered. If
they're small, we should discuss it on the channel or list, and
if there's a consensus, make it a hard libdepend. cups-libs or
fam are examples of this - it's not really required to build KDE, but we
force it because it's small, and for KDE to take advantage of
it at runtime, it must have been present at build time.
If there's no consensus, it's big (for some value of big, which
I guess we haven't really established yet, but bigger than
a 500kb distfile would be hitting my upper limit) or the
functionality offered is quite specific to only a few users,
make it an option that can be specified with 'make WITH_FOO'
All dependencies need to be accounted for, especially the ones
that are 'hidden'. An example of this is the ldap dependency in
kdelibs. It's not required for building, but if detected, ldap
support will be built, and there's not currently any way to
turn that off. If it's built however, extra files are
compiled, which means the packing lists change, so it must be
covered with an option AND a test for the lib.
Make sure any options that change the plists have a line in the
Makefile to merge in the extra plist, so it's ready to go when
you go to the next step.
e) Check that the plists have not changed. Between minor version
upgrades, mostly it's i18n that will have changed plists.
If the port has NO options, then the cluster can generate the plists,
you don't have to care for it.
If the port has options, you need to generate plists. The
cluster can generate the basic plist (the 'built with all default
options' one) so we might want to hold this over until the first
cluster run has built.
5) Ananas is prepped for an initial run.
The first run should do .autopkg for all ports, to generate the
plists (and should continue to do so until we have a successful
plist generation for every port)
At that point, we'll have the basic plists for every port created
already, and packages for initial testing, and for kdelibs and
kdebase, so that we can use our own machines to work on the extra
plists for merging.
6) Compile-time or ports bug fixes made.
7) Go to step 5 and repeat as necessary.
8) Announce packages for testing purposes.
9) Runtime bug fixes made, go to step 5 and repeat as necessary.
10) Final packages are posted to ktown for release.
11) KDE releases x.y.z.
12) Final diff is made between original FreeBSD versions and the
versions at the end of step 10.
13) Diff is committed to FreeBSD repo.
To edit this content, you must have an account on sirius:
setenv CVS_RSH ssh # if required cvs -d<user>@sirius.firepipe.net:/home/kde-freebsd co devdocs
This file is called: ports-update-procedure
Content last modified: Wednesday, 20-Aug-2003 17:04:13 CEST