[pacman-dev] Breaking change in pacman from 5.0.1 -> 5.0.2 with regards to user account resolution

Thomas Karlsson thomas.karlsson at paneda.se
Wed Jun 21 08:56:46 UTC 2017


Ok, thanks brainpower and Eli!

>This is eminently reasonable, since it is after all the recommended, proper way to do things. It is also why we have >https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database to track standardized UID/GID numbers for packages in the official repos.
>
>You can specify the desired UID/GID for a new system user in the
>sysusers.d(5) snippet that originally created the user.

Great, thanks for those links! I can see that I was not using the recommended workflow.

However, I am still surprised to see such a breaking change to be released in a patch release without it even being mentioned in the release notes/news. Seems a bit harsh to me.

From the link given by brainpower I'm apparently not the only one who thinks using the username as key instead of UID is a good (or at least feasible) idea...

" This sounds like the expected behavior.  The user/group names are
>>> stored in the archive if they exist on the system building the package
>>> and bsdtar will use the names rather than the id's by default when
>>> extracting the archive."

So, perhaps more people will run into this behavioral change as well.

Anyway. I will switch to using UID numbers instead of username now.
Thanks,

Best regards,
Thomas

-----Original Message-----
From: pacman-dev [mailto:pacman-dev-bounces at archlinux.org] On Behalf Of Eli Schwartz
Sent: den 20 juni 2017 23:03
To: pacman-dev at archlinux.org
Subject: Re: [pacman-dev] Breaking change in pacman from 5.0.1 -> 5.0.2 with regards to user account resolution

On 06/20/2017 10:52 AM, Thomas Karlsson wrote:
> Hello!
> 
> I have several packages that install files that need to be owned by 
> specific users on the target system. To achieve that I'm using the 
> install command with the -o <username> and -g <group name> flags in 
> the package() function. I'm not using a install script with a
> post_install() function.
> 
> Example of the relevant part of the package function
> 
> package() { install -m 600 -o username -g groupname the_file 
> "$pkgdir"/some/path/to/the_file }
> 
> The package is built on a build server and then installed on a number 
> of targets. This has worked fine up until I upgraded to 5.0.2
> 
> After upgrading pacman to 5.0.2 the file does not get the correct 
> owner on the target system any more. It gets own by the user that has 
> the UID that the user has on the build server which is not the same 
> UID as the user has on the target.
> 
> To clarify. In my setup the UID of the user is different on the build 
> server compared to the UID of the target system. Before this did not 
> matter. The file got the correct ownership anyway. After 5.0.2 the 
> file gets owned by whatever user account that has the UID and GID that 
> the user has on the build server no matter what UID and GID the user 
> has on the target system.
> 
> As far as I can tell this is probably the commit that changed the 
> behavior
> https://git.archlinux.org/pacman.git/commit/?h=release/5.0.x&id=908769
> b54002e104b90ab2b3e5ca8066affd4394
>
> 
> 
> Temporarily I have changed my PKGBUILD file to specify UID and GID 
> that the target system has instead of the username and groupname on 
> the install command but this seems fragile as it now requires that the 
> UID/GID is the same on all target systems. Both existing and future.

This is eminently reasonable, since it is after all the recommended, proper way to do things. It is also why we have https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database to track standardized UID/GID numbers for packages in the official repos.

You can specify the desired UID/GID for a new system user in the
sysusers.d(5) snippet that originally created the user.

> Is this an unintended side effect of the commit referenced above, or 
> is this the expected behavior?

Seems to me as though your workflow *was* the bug that this commit fixed. :)

--
Eli Schwartz



More information about the pacman-dev mailing list