Date: Wed, 08 Oct 2014 08:40:00 +0200 From: Matthias Andree <mandree@FreeBSD.org> To: Bryan Drewery <bdrewery@FreeBSD.org>, ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r370388 - in head: devel/e2fsprogs-libss misc/e2fsprogs-libblkid misc/e2fsprogs-libuuid sysutils/e2fsprogs sysutils/e2fsprogs/files Message-ID: <5434DC40.7050807@FreeBSD.org> In-Reply-To: <5434864D.7000204@FreeBSD.org> References: <201410071915.s97JFrQo061043@svn.freebsd.org> <54344848.1040707@FreeBSD.org> <54347CBA.1050206@FreeBSD.org> <5434864D.7000204@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 08.10.2014 um 02:33 schrieb Bryan Drewery: > On 10/7/2014 6:52 PM, Matthias Andree wrote: >> I am not sure I got what you're trying to convey. You may be >> overestimating the scope of the issue, given the findings after the commit. >> >> I do not consider 11-CURRENT a reference, nor is 11 a "RELEASE". > > I knew you would get tripped up on the word 'release'. It still does not > change my point. The port was working, and now is not. Now we provide no > package for head users because of an upgrade. It's really an > unacceptable situation to me. > > My private mail to you was implying that if ports could support multiple > versions per origin (like gentoo portage), then you could mark the > default version was your updated one on all branches/releases except > head, where it could remain the working version. Hi Bryan, Ah that's whence your "one version" came. General statements: I don't object to supporting OSVERSION-dependent port versions, and time lines permitting, I'd be happy to review concepts and specifications (i. e. documents) how we want to do that in ports, rather than see people rush forward with code without a sound concept, but I don't think it will buy us much. Arguably poudriere as the builder infrastructure might want to do atomic port replacements in its repository, i. e. only replace the port and its Latest/ link in particular if it could build successfully and is not marked BROKEN/FORBIDDEN/... Regarding metadata on the rollback, I am trying to avoid PORTEPOCH because it is an abomination (also because the epoch is being postfixed with comma, although it is the most significant component in the version designation and hence should be prefixed), we would have to lug this around forever for what I believe will be a temporary situation. I'd rather call the portversion 1.42.12.0.1.42.10_rolledback or something because that is then temporary and I can roll forward to 1.42.12.1 (instead of 1.42.12_1) or 1.42.13. Further e2fsprogs-1.42.12-specific statements: It all wouldn't really save the packages this time though since it turns out that 11-CURRENT uncovered bugs present on all systems but not normally exposed by the self-test suite. export MALLOC_OPTIONS=J and see the port fail on FreeBSD 9, for instance, too. So we don't have the package at all for now, unless someone reverts the port back to 1.42.10, but I propose to wait for upstream's response (none yet) for a few days. Anyone who needs the package and wants to risk its misprocessing can build it with "TRYBROKEN=23" or downgrade the port. I still hope upstream can come up with a patch shortly so we can just move forward to 1.42.12_1 and go on with life. I think we have bigger fish to fry than wasting time on 100% availability of a low-profile package. Let's wait what we get before the weekend and then decide if we go forward with a yet-to-come upstream patch or new release, or if we go backward to the previous version. If someone thinks e2fsprogs is a high-profile port (FreeNAS or PCBSD default install, whichever), please fill me in. Cheers, Matthias
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5434DC40.7050807>