Allan McRae wrote:

No idea... I generated the list via a quick grep, so there are false positives (more than I expected...). Just mark them as done.

A

It seems that it also didn't catch install files from split packages, eg. kdepim or kdewebdev are missing from the todo list.

Allan McRae wrote:

On 28/04/16 21:18, Antonio Rojas wrote:

...

Allan McRae wrote:

...

No idea... I generated the list via a quick grep, so there are false positives (more than I expected...). Just mark them as done.

A

It seems that it also didn't catch install files from split packages, eg. kdepim or kdewebdev are missing from the todo list.

Is the base package there?

No, neither the base package nor any of its subpackages.

Allan McRae wrote:

Hrm... it was on the list I uploaded.

$ grep kdepim rebuild.txt kdepim kdepimlibs kdepimlibs4 kdepim-runtime

Ah, so the issue is todo lists not accepting pkgbases as input

You have obviously figured it out so who cares...

Yeah but there could be more packages affected

On 28/04/16 04:40, Anatol Pomozov wrote:

Hi

And another related question: are we going to have hooks for systemd-sysusers and systemd-tmpfiles?

Quite a lot of packages packages use systemd-tmpfiles and it sounds like a good idea to move it to hooks.

They are listed on the wiki page [1] and this rebuild was labelled as "#1", so you could concluded there will be another rebuild... [1] https://wiki.archlinux.org/index.php/DeveloperWiki:Pacman_Hooks

On 04/28/2016 12:28 PM, keenerd wrote:

Namcap 3.2.7 is released. It removes the old .install warnings and adds a new one if the .install does anything covered by a hook.

All it needs is a dev to update the package.

Updated. Tested with some of my rebuilds and it works nicely. Thanks! -- Regards, Felix Yan

On 4/28/16, Balló György wrote:

...

Namcap 3.2.7 is released. It removes the old .install warnings and adds a new one if the .install does anything covered by a hook.

Note that checks for shared-mime-info and desktop-file-utils dependencies are still needed. Please restore them.

My bad! They were mixed together with the .INSTALL tests. Restored and massively refactored. No update for this one since the issue only created a few largely harmless false negatives, and I imagine there will be another update soon enough for rebuild #2. -Kyle

On Thu, 28 Apr 2016 09:29:49 -0700 Anatol Pomozov wrote:

Hi

On Wed, Apr 27, 2016 at 11:36 PM, Balló György wrote:

...

2016-04-28 6:28 GMT+02:00 keenerd :

...

Namcap 3.2.7 is released. It removes the old .install warnings and adds a new one if the .install does anything covered by a hook.

Note that checks for shared-mime-info and desktop-file-utils dependencies are still needed. Please restore them.

I disagree.

Dependencies like gtk-update-icon-cache/desktop-file-utils should be installed by those who *needs* the tool functionality. Not by the packages that *provide* icons/desktop files.

It this case desktop environment should depend on desktop-file-utils that maintains the cache up-to-date. And if a user has no UI (headless setup) then no point in updating this cache.

While I agree completely, Allan brought up the case of installing the tool after the fact, which won't necessarily trigger the hook. In the example you gave, the desktop mime cache wouldn't be created until you install something else with a .desktop file. More things would need the desktop mime cache, though, such as xdg-utils. This would pull it in on many more systems.

On 04/28/16 at 09:52am, Anatol Pomozov wrote:

Hi

On Thu, Apr 28, 2016 at 9:38 AM, Doug Newgard wrote:

...

On Thu, 28 Apr 2016 09:29:49 -0700 Anatol Pomozov wrote:

...

Dependencies like gtk-update-icon-cache/desktop-file-utils should be installed by those who *needs* the tool functionality. Not by the packages that *provide* icons/desktop files.

It this case desktop environment should depend on desktop-file-utils that maintains the cache up-to-date. And if a user has no UI (headless setup) then no point in updating this cache.

While I agree completely, Allan brought up the case of installing the tool after the fact, which won't necessarily trigger the hook. In the example you gave, the desktop mime cache wouldn't be created until you install something else with a .desktop file.

I think it makes sense to enhance the hook system to make sure hook is run when it is installed. But if it cannot be done then "update cache" should be run in post_install() of desktop-file-utils similar to what gtk-update-icon-cache package does [1].

Hooks already run during the transaction that installs them if something in the transaction triggers them. Running them on installation even when they're *not* triggered, makes no sense. If the process requires the list of new/updated/removed files, the post_install script needs to scan the filesystem and build the initial cache; the hook can then manage updates to it. If the list of files is not needed you can either build the initial cache from the post_install script or just have the hook trigger itself.

...

More things would need the desktop mime cache, though, such as xdg-utils. This would pull it in on many more systems.

I agree that xdg-utils uses desktop mime cache and it should depend on desktop-file-utils.

[1] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/gtk-update-i...

2016-04-28 7:12 GMT+02:00 Jan Alexander Steffens :

On Thu, Apr 28, 2016 at 12:09 AM, Anatol Pomozov wrote:>

...

And one more note: there are a lot of packages that have a dependency to "desktop-file-utils/gtk-update-icon-cache/..." package because the tools were used in *.install file. With the hook these dependencies are needed anymore. Please look at the dependency list of the packages you update and clean it up if needed.

No, dependencies ensure the hook is available.

+1 Only xdg-utils should be replaced with gtk-update-icon-cache when it's used by the install script to run 'xdg-icon-resource forceupdate'. I recommend to add gtk-update-icon-cache as dependency to hicolor-icon-theme, since if a package uses the hicolor theme hierarchy, then it should update its icon cache too. -- György Balló

On Thu, 28 Apr 2016 14:23:27 +0300, Jan Alexander Steffens wrote:

It seems libvirt just lost its systemd-tmpfiles call even though it's not on the list. Were any other packages similarly affected?

+ motion and apcupsd from my packages.