• List of FHS approved install directories

    From Lance Fredrickson@21:1/5 to All on Thu Feb 10 18:40:01 2022
    I've noticed that installing a self created package to a non-FHS
    compliant directory will the give the message "dpkg: warning: while
    removing directory /usr/local not empty so not removed" upon removal of
    the package. Where in the source code does it list these FHS compliant directories?  I'm compiling dpkg for a personal project and would like
    to modify the list of directories that dpkg thinks are FHS compliant.

    thanks,
    Lance Fredrickson

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Guillem Jover@21:1/5 to Lance Fredrickson on Thu Feb 10 19:00:01 2022
    Hi!

    On Thu, 2022-02-10 at 10:34:36 -0700, Lance Fredrickson wrote:
    I've noticed that installing a self created package to a non-FHS compliant directory will the give the message "dpkg: warning: while removing directory /usr/local not empty so not removed" upon removal of the package. Where in the source code does it list these FHS compliant directories?  I'm compiling dpkg for a personal project and would like to modify the list of directories that dpkg thinks are FHS compliant.

    dpkg has no built-in knowledge about any filesystem layout (and it will
    be kept that way). What you are seeing is those pathnames not being
    owned by any package, although they are created (at least on Debian
    and derivatives) by the base-files package maintainer scripts:

    $ dpkg-query --control-show base-files postinst

    In the future this might be fixable, once dpkg can support for
    packages to declare a pathname to be created by allowing for it to be
    removed, which is the main reason (AFAIR) that base-files is not
    shipping them in the .deb as is usual.

    For now your alternatives are to ship the files under /usr instead of /usr/local (as that's supposed to be the location for manually handled
    files by local admins, or at least that's how I interpret it), and
    dpkg should be able to protect against file collisions anyway, and if
    you have those already then what is being used will depend on
    precedence given by specific callers or environment settings. Or perhaps
    create some kind of base-something packages, that ships those pathnames,
    but once/if you remove it you'll get the same warnings.

    Thanks,
    Guillem

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lance Fredrickson@21:1/5 to Guillem Jover on Thu Feb 10 19:20:01 2022
    Perfect, thanks for the quick and concise answer!

    Lance

    On 2/10/2022 10:51 AM, Guillem Jover wrote:
    Hi!

    On Thu, 2022-02-10 at 10:34:36 -0700, Lance Fredrickson wrote:
    I've noticed that installing a self created package to a non-FHS compliant >> directory will the give the message "dpkg: warning: while removing directory >> /usr/local not empty so not removed" upon removal of the package. Where in >> the source code does it list these FHS compliant directories?  I'm compiling
    dpkg for a personal project and would like to modify the list of directories >> that dpkg thinks are FHS compliant.
    dpkg has no built-in knowledge about any filesystem layout (and it will
    be kept that way). What you are seeing is those pathnames not being
    owned by any package, although they are created (at least on Debian
    and derivatives) by the base-files package maintainer scripts:

    $ dpkg-query --control-show base-files postinst

    In the future this might be fixable, once dpkg can support for
    packages to declare a pathname to be created by allowing for it to be removed, which is the main reason (AFAIR) that base-files is not
    shipping them in the .deb as is usual.

    For now your alternatives are to ship the files under /usr instead of /usr/local (as that's supposed to be the location for manually handled
    files by local admins, or at least that's how I interpret it), and
    dpkg should be able to protect against file collisions anyway, and if
    you have those already then what is being used will depend on
    precedence given by specific callers or environment settings. Or perhaps create some kind of base-something packages, that ships those pathnames,
    but once/if you remove it you'll get the same warnings.

    Thanks,
    Guillem

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)