Bump pkgrel just to force recompilation

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bump pkgrel just to force recompilation

Justus-dev
Hi -

I keep running into problems caused by stale installations from the AUR,
such as upgraded, ABI-incompatible dependencies or Python packages still
installed under /usr/lib/python3.5/ where they are no longer found since
the move to python3.6.

My understanding is that in such situations, the affected packages
should bump pkgrel to force rebuild and reinstall, even if the source
and the rest of the PKGBUILD remain unchanged.

Is this understanding correct?  If so, can this be clarified in places
such as [1][2] where people cannot miss it?

Confronted with this issue, some maintainers advise their users to just
rebuild by hand, but that defeats part of the purpose of package
management systems.  I don't want to have to debug weird run-time errors
one by one, trace the problem to this trivial issue, and then solve each
of them by manual rebuild.

Justus


[1] https://wiki.archlinux.org/index.php/PKGBUILD#pkgrel
[2] https://wiki.archlinux.org/index.php/Arch_User_Repository
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bump pkgrel just to force recompilation

G. Schlisio-2
Am 10.08.2017 12:33, schrieb [hidden email]:

> Hi -
>
> I keep running into problems caused by stale installations from the
> AUR,
> such as upgraded, ABI-incompatible dependencies or Python packages
> still
> installed under /usr/lib/python3.5/ where they are no longer found
> since
> the move to python3.6.
>
> My understanding is that in such situations, the affected packages
> should bump pkgrel to force rebuild and reinstall, even if the source
> and the rest of the PKGBUILD remain unchanged.
>
> Is this understanding correct?  If so, can this be clarified in places
> such as [1][2] where people cannot miss it?
>
> Confronted with this issue, some maintainers advise their users to just
> rebuild by hand, but that defeats part of the purpose of package
> management systems.  I don't want to have to debug weird run-time
> errors
> one by one, trace the problem to this trivial issue, and then solve
> each
> of them by manual rebuild.
>
> Justus
>
>
> [1] https://wiki.archlinux.org/index.php/PKGBUILD#pkgrel
> [2] https://wiki.archlinux.org/index.php/Arch_User_Repository

Hi Justus,

in my opinion, pkgrel is to be bumped when something with regard to the
package changes, not for the sake of rebuild only.
Keeping track of rebuilds is the users task, you could e.g. after a
python update go through all remaining files in the old versions folder
and initiate a rebuild of the corresponding packages.
This is easily scriptable and should be regarded as usual update hygiene
like ocassionally checking /var/cache/pacman and other tasks.
Arch is not about fully automating everything and hiding the internal
workings from the user.
About the debugging: when a major update happens, you are usually
informed about the necessary actions in the pacman output. Paying
attention to that is not optional in Arch.

best
Georg
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bump pkgrel just to force recompilation

Eli Schwartz-2
In reply to this post by Justus-dev
On 08/10/2017 06:33 AM, [hidden email] wrote:

> Hi -
>
> I keep running into problems caused by stale installations from the AUR,
> such as upgraded, ABI-incompatible dependencies or Python packages still
> installed under /usr/lib/python3.5/ where they are no longer found since
> the move to python3.6.
>
> My understanding is that in such situations, the affected packages
> should bump pkgrel to force rebuild and reinstall, even if the source
> and the rest of the PKGBUILD remain unchanged.
>
> Is this understanding correct?  If so, can this be clarified in places
> such as [1][2] where people cannot miss it?
>
> Confronted with this issue, some maintainers advise their users to just
> rebuild by hand, but that defeats part of the purpose of package
> management systems.  I don't want to have to debug weird run-time errors
> one by one, trace the problem to this trivial issue, and then solve each
> of them by manual rebuild.
The problem is that there really isn't an official rule. Some people
feel that "users should know and check for themselves", some people feel
that maintainers should be responsible for making sure people know to
upgrade.

My personal feeling on the matter is that both of these arguments are
completely missing the point.
pkgrel is supposed to monotonically increase on each rebuild of the
package. If the maintainer doesn't do that on the AUR, then users would
have to do that themselves, by editing the PKGBUILD. As a result, there
is a lousy choice between not knowing when the maintainer pushes a
different pkgrel update because e.g. changed dependencies/build()
function, and having no sane upgrade path but being forced to reinstall
the same $pkgver-$pkgrel (and among other things, this will break the
model used by aurutils).

To my great displeasure, I have no actual way of enforcing reason on the
entire world. :D

--
Eli Schwartz


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bump pkgrel just to force recompilation

Doug Newgard-2
On Thu, 10 Aug 2017 10:26:09 -0400
Eli Schwartz <[hidden email]> wrote:

> pkgrel is supposed to monotonically increase on each rebuild of the
> package.

Which is completely invalid in the AUR. How is the maintainer supposed to keep
the user from doing rebuilds in between?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bump pkgrel just to force recompilation

xyne
In reply to this post by Eli Schwartz-2
Eli Schwartz wrote:

>pkgrel is supposed to monotonically increase on each rebuild of the
>package.

When releasing a binary package, the pkgrel needs to be bumped if the resulting
package's signature and/or checksums change (without changing the pkgver).

When releasing a PKGBUILD the requirement is not the same. The pkgrel should be
bumped when rebuilding the old and new packages side-by-side would result in
different packages with the same version due to e.g. metadata changes (desc,
depends, license, url, etc.) or different build flags or installed files.
Values that do not affect the final package can be changed without a pkgrel
bump, such as checksums or download sources.

There is no rule on the AUR. Bumping the pkgrel is a workaround to help package
manager that lack awareness of build dependencies. It doesn't hurt but it's not
required. It is always the user's responsibility to manage rebuilds on the AUR.

Incidentally, there are tools to assist the user (e.g. pkg-list_unrebuilt script [1]).

Regards,
Xyne

[1] https://xyne.archlinux.ca/projects/pkg_scripts/#help-message-pkg-list_unrebuilt
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bump pkgrel just to force recompilation

beest
In reply to this post by Doug Newgard-2
On Thu, Aug 10, 2017 at 09:41:39AM -0500, Doug Newgard wrote:
> On Thu, 10 Aug 2017 10:26:09 -0400
> Eli Schwartz <[hidden email]> wrote:
>
> > pkgrel is supposed to monotonically increase on each rebuild of the
> > package.
>
> Which is completely invalid in the AUR. How is the maintainer supposed to keep
> the user from doing rebuilds in between?

Why, because pkgrel is now out of sync with the AUR? The user can just bump the
release a minor version, which pacman handles just fine and will still
see an upgrade the next time the maintainer updates the package.
Loading...