svn commit: r364287 - head/ports-mgmt/pkg-devel

[Adam Weinberger]

On 11 Aug, 2014, at 11:33, Bryan Drewery <bdrewery at 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 at 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.

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


-- 
Adam Weinberger
adamw at adamw.org
http://www.adamw.org