Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Aug 2014 11:51:49 -0400
From:      Adam Weinberger <adamw@adamw.org>
To:        Bryan Drewery <bdrewery@FreeBSD.org>
Cc:        svn-ports-head@freebsd.org, Vsevolod Stakhov <vsevolod@freebsd.org>, svn-ports-all@freebsd.org, ports-committers@freebsd.org, Matthias Andree <matthias.andree@gmx.de>, Tijl Coosemans <tijl@freebsd.org>
Subject:   Re: svn commit: r364287 - head/ports-mgmt/pkg-devel
Message-ID:  <2DE6FE39-3176-452C-B595-812B83616373@adamw.org>
In-Reply-To: <88dcf721a5ea4bccfb3cf424da694c72@shatow.net>
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> <88dcf721a5ea4bccfb3cf424da694c72@shatow.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 11 Aug, 2014, at 11:33, Bryan Drewery <bdrewery@FreeBSD.org> wrote:

> 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?
>=20
> I explained this in private to someone else as well...
>=20
> 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.
>=20
> I dislike how it is all handled honestly. It destroys the idea of a =
reproducible package.

Can one of the build cluster machines start logging the actual shlib =
links of each port, after the package is built? That would make it so =
deliciously easy, if a porter could just ask the system for a =
comprehensive list of every port that contains links to a specific =
library.

# Adam


--=20
Adam Weinberger
adamw@adamw.org
http://www.adamw.org




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2DE6FE39-3176-452C-B595-812B83616373>