Date: Mon, 11 Aug 2014 10:33:43 -0500 From: Bryan Drewery <bdrewery@FreeBSD.org> To: Vsevolod Stakhov <vsevolod@freebsd.org> Cc: svn-ports-head@freebsd.org, Tijl Coosemans <tijl@freebsd.org>, Matthias Andree <matthias.andree@gmx.de>, svn-ports-all@freebsd.org, ports-committers@freebsd.org Subject: Re: svn commit: r364287 - head/ports-mgmt/pkg-devel Message-ID: <88dcf721a5ea4bccfb3cf424da694c72@shatow.net> In-Reply-To: <53E7D193.3090305@FreeBSD.org> References: <53e39939.55bc.4ca5432c@svn.freebsd.org> <20140807172841.58633e63@kalimero.tijl.coosemans.org> <53E3A468.5050603@FreeBSD.org> <53E3AC0C.5020904@gmx.de> <53E3AD09.2050000@FreeBSD.org> <53E3B3B5.9000104@gmx.de> <53E3B6D8.9080101@FreeBSD.org> <53E590AC.4020105@FreeBSD.org> <53E7A512.8050008@FreeBSD.org> <b1c74ebef13a04a7198ed4a34134d63a@shatow.net> <53E7D193.3090305@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2014-08-10 15:09, Vsevolod Stakhov wrote: > On 10.08.2014 20:40, Bryan Drewery wrote: >> On 2014-08-10 12:00, Vsevolod Stakhov wrote: >>> Bryan, >>> >>> On 09/08/14 04:08, Bryan Drewery wrote: >>>> On 8/7/2014 12:26 PM, Vsevolod Stakhov wrote: >>>>> On 07/08/14 18:13, Matthias Andree wrote: >>>>>> Am 07.08.2014 um 18:44 schrieb Vsevolod Stakhov: >>>>>> >>>>>>> On 07/08/14 17:40, Matthias Andree wrote: >>>>>>>> Am 07.08.2014 um 18:08 schrieb Vsevolod Stakhov: >>>>>>>> >>>>>> [skipped] >>>> >>>> I'm not convinced about this change. We have fixed the >>>> wine-devel-i386 >>>> which was unrelated to soname version. >>>> >>>> Will stripping .so.* break automatic reinstalling when shlibs >>>> change? >>>> That is a critical feature. >>>> >>> >>> I think, I've described in details the current issue with that at >>> #pkgng@freenode. Briefly, this change does not break "automatic >>> reinstalling when shlibs change" as it doesn't work now. >> >> If it "does't work now" it needs to be fixed. This is a regression >> over >> 1.2. Not automatically reinstalling packages when dependent shlibs >> change breaks a lot of packages. Port revision bumps do not always >> occur. Auto reinstalling for changed SHLIBS and OPTIONS is very >> important. > > See below. > >> Poudriere will automatically rebuild packages if their dependencies >> are >> updated regardless of a revision bump. If no bump occurs, yet a shlib >> is >> bumped, the package is updated. Pkg 1.2 would detect this and >> reinstall >> the packages depending on that shlib. If we are now ignoring the >> version, and it doesn't work otherwise, then we are leaving people >> with >> broken systems where the only way to handle it is 'pkg upgrade -f' >> every >> time. >> >> I understand the problem you describe of .so.X vs .so.X.Y, but this >> functionality was present during most of the RC and 1.3 releases >> right? >> It was changed due to wine? The wine issue is unrelated and is now >> fixed. I would think the more safe route would be to strip .X.* and >> keep >> .X rather than strip the entire version. > > The problem with .so was *not* related to wine. It was related to > inconsistency between provides and requires. And as far as I see it is > *not* fixed yet. > > Regarding auto install... > I would like to repeat here what I have written prior to 1.3 release: > > >> Let me explain the situation with pkg. Pkg needs to find so called >> ``upgrade chains'' that are used to upgrade packages. To find out >> packages that are suitable for upgrade we use origins in pkg 1.2 and >> name~origin in pkg 1.3. >> >> However, each package is identified by a special field called >> `manifestdigest'. In pkg 1.2, this field is just sha256(manifest). >> Unfortunately, this means that if *any* field of a package is changed >> a >> version bump is required. By fields I mean files and directories as >> well >> which leads thus to a policy where we need to bump a revision even if >> we >> have meaningless changes in the files a package provides (that happens >> after this particular change). >> >> With pkg 1.3 this behaviour has been changed to recognize the >> following >> fields only: >> >> * name >> * origin >> * version >> * arch >> * maintainer >> * www >> * message >> * comment >> * options >> >> Hence, I think that with the release 1.3 of pkg we should define >> revision bump policy to reflect this change. > > So I asked *many* times (in irc, mailing lists, private conversations) > what fields are considered to be significant, but got only few good > suggestion. And now, after 1.3 is released, changing that requires > more testing: > > https://github.com/freebsd/pkg/pull/911 > > This patch, for example, does this. But I haven't tested it yet and I > don't know what side effects could it cause. > > Nonetheless, doesn't our ports policy defines to bump PORTREVISION in > all cases that modifies a resulting package? Shlib provides/requires > changing is definitely such a change. So you blame now pkg that it > follows the current policy, don't you? I explained this in private to someone else as well... Yes it is the policy, but it is a different thing with packages. If a bump is missed for ports users it is not a big problem as they can remedy it with portmaster by rebuilding ports depending on the changed shlib. Package users have no way to fix their packages, so the remote must have rebuilt them to link to the new library so the user can have a working system without needing to checkout ports every time a committer is lazy about chases. Without a bump, or pkg handling it, it would result in the user being forced to reinstall packages one by one or with upgrade -f, or saving all shlibs in /usr/local/lib/compat/pkg. It's an ugly situation. I dislike how it is all handled honestly. It destroys the idea of a reproducible package. -- Regards, Bryan Drewery
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?88dcf721a5ea4bccfb3cf424da694c72>