[pacman-dev] Remove directory symlink support in pacman-4.2 - Was: Use resolved paths for filelist operations

[Jason St. John]

On Sat, Feb 16, 2013 at 8:14 PM, Allan McRae <allan at archlinux.org> wrote:
> On 16/02/13 12:02, Andrew Gregory wrote:
>> Properly handling symlinks requires using resolved paths.  I'm not sure if
>> returning strings instead of file_t structs is the best solution, but it seemed
>> like the least drastic one as we prepare for 4.1 and we weren't using the extra
>> information anyway.
>
> Thanks for catching this and the patches - I made one small comment.
>
>
> This whole situation is beginning to really annoy me...   I know we
> (especially you) have put a lot of work to get symlinks to directories
> working so that when /lib -> usr/lib we now can deal with /lib/foo and
> /usr/lib/foo conflicting etc, but having to stat every directory to
> determine if it is a symlink and the resolve it is just wrong.
>
> So here is what I am proposing.  Get pacman-4.1 out the door with these
> patches included.   Then the sole focus of pacman-4.2 should be
> stripping support of symlinks to directories out of pacman.  If /lib is
> a symlink on your system, no packages should put files in /lib.  Just
> make that a conflict.  If a package MUST put files there, the package()
> function in the PKGBUILD should look like:
>
> package() {
>   ln -s usr/lib ${pkgdir}/lib
>   make install
>   rm ${pkgdir}/lib
> }
>
> Done...
>
> The only other reason these are used (that I have seen...), is poor
> man's mount points.  For example, your /usr partition is getting full
> and you decide to put it on your /home partition in /home/share (yes - I
> have seen that done...).  The are more correct options that should be
> used here - preferably resize your partitions or create a new partition.
>  On Linux, a bind mount could be used.
>
> Overall, I see no need to keep this mis-feature.
>
>
> So, I am proposing, get this patchset merged and get pacman-4.1 out the
> door.  The just concentrate removing all directory symlink support from
> pacman.
>
> The only thing that would need to be done here is to check all current
> packages do not have paths in them that require resolving symlinks to
> directories.   E.g. on machines with /lib -> usr/lib, no package should
> have a file in /lib.  I propose that in a 4.1.x point release, we should
> add a tool (or perhaps extend testdb) to detect these packages and print
> a warning.  So a bit of planning is needed, but I think it can be done.
>
> Comments?
>
> Allan
>
>
>
>

Does namcap currently warn about "official symlinks", such as /lib ->
usr/lib? If not, it would be good to have namcap warn about these so
problematic PKGBUILDs can be cleaned up sooner rather than later. This
wouldn't help for custom symlinks, such as the /home/share kludge you
mentioned, but I still see some value in it.

Jason