On Sun, 28 Feb 2016 12:54:46 +0100 Adriaan de Groot <gr...@kde.org> wrote:
> Having rebuilt everything using area51 trunk (KDE4), I was about to upgrade > my > system using all the packages built from area51 trunk. Most of it seems > sensible: > > Installed packages to be UPGRADED: > telepathy-qt4: 0.9.4 -> 0.9.5 > ... > automoc4: 0.9.88_4 -> 0.9.88_5 > attica: 0.4.2,2 -> 0.4.2_1,2 > > But there's also cases where ports are actually unchanged in trunk, but are > missing a PORTREVISION that matches official ports. This makes it seem like a > downgrade: > > Installed packages to be DOWNGRADED: > soprano: 2.9.4_1 -> 2.9.4 > raptor2: 2.0.15_1 -> 2.0.15 > qt4-corelib: 4.8.7_2 -> 4.8.7 > nepomuk-core: 4.14.3_3 -> 4.14.3_1 > libstreams: 0.7.8_1 -> 0.7.8 > libstreamanalyzer: 0.7.8_5 -> 0.7.8_2 > libkfbapi: 1.0_3 -> 1.0 > > kfilemetadata: 4.14.3_3 -> 4.14.3 > > ebook-tools: 0.2.2_3 -> 0.2.2 > > > I'm wondering what to do with these. I would expect this to complicate a > merge > into ports a little. Here's what seems to be the differences: > > soprano: 2.9.4_1 -> 2.9.4 > Only PORTREVISION and USES=tar:bz2 vs USES=tar:bzip2. Portrevision was bumped > in ports r353029; that change is incorporated in trunk. > > raptor2: 2.0.15_1 -> 2.0.15 > Only PORTREVISION. Bumped for an ICU update in april 2015. > > qt4-corelib: 4.8.7_2 -> 4.8.7 > PORTREVISION bumped twice. r402613 and r408855. Both changes are also in > trunk > (except for the bump). > > nepomuk-core: 4.14.3_3 -> 4.14.3_1 > Bumped for libzip update in r395464 and poppler in r406872. > > libstreams: 0.7.8_1 -> 0.7.8 > Bumped in r344139 and then most of that change reverted in 395972. > > libstreamanalyzer: 0.7.8_5 -> 0.7.8_2 > Most recently bumped for NEW XORG in r351411 > > libkfbapi: 1.0_3 -> 1.0 > > Bumped for gcc update in 2014. > > kfilemetadata: 4.14.3_3 -> 4.14.3 > > Bumped for libzip and poppler. > > ebook-tools: 0.2.2_3 -> 0.2.2 > > Bumped for libzip. > > > So I'd like to reintroduce the PORTREVISIONS for these ports -- which are all > essentially unchanged from official ports -- so that they don't seem like a > downgrade. > > But there's an underlying question here: should trunk follow ports closely > except for the-ports-that-are-being-prepared-for-update, or not? > > [ade] Go ahead. Most of those ports in area51's lack of PORTREVISION is likely my doing, as I strip them of the PORTREVISION bits because area51 used to have newer versions of those ports than FreeBSD PORTS. In fact, the lack of PORTREVISION breaks area51-based installations quite often, because the neccessity to rebuild a port becomes hidden. Alonso
pgpQ28H0Wu3Ak.pgp
Description: PGP signature
_______________________________________________ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
