Allow custom file destination for Linux packages

[claunia]

In my use case I must provide my own desktop file as my application is dual (CLI/GUI) and the desktop file need to pass parameters to run the application in GUI mode, plus also I provide a MIME registry file that needs to go in /usr/share/mime/packages.

quamotion's tool used this way:

    <Content Include="aaruformat.xml" CopyToPublishDirectory="PreserveNewest" LinuxFileMode="0644">
      <LinuxPath>/usr/share/mime/packages/aaruformat.xml</LinuxPath>
    </Content>

[SuperJMN]

Interesting. What kind of package are you trying to create?

[claunia]

Standard deb and rpm packages.

[eugenelarin]

I'm in the same situation. I'm bundling third-party binaries that should have sufficient permissions.

[SuperJMN]

Thanks a lot for the detailed request, and for the concrete examples. This is very helpful.

I completely understand the need, especially for advanced scenarios like custom desktop launch behavior, MIME registration, or shipping extra binaries.

That said, I want to be careful with this one because DotnetPackaging is intentionally designed to be a high-level packaging tool with as little configuration as possible. The main goal is that most users can package an app by providing only a few high-level properties, and the tool generates the package layout automatically.

A fully generic feature like “place any file at any destination path” would definitely solve your case, but it also adds a lot of flexibility/complexity that may make the tool harder to use and maintain.

So for now I’m hesitant to add a generic custom-destination mechanism.

Could you share a bit more about your exact use case so I can evaluate whether we can support it later with a simpler high-level option instead?

For example:

• Which format(s) do you need (deb, rpm, both)?
• What exact files do you need to add/override?
• What is the generated .desktop file missing for your scenario?
• Is the main need custom Exec= arguments, MIME registration, file permissions, or something else?

If I see a repeated/common pattern, I’d prefer adding a targeted option (or a small set of targeted options) instead of a fully generic file mapping system.

Thanks again for raising it.

[SuperJMN]

@eugenelarin thanks for adding that context, that’s very useful.

Just to better understand your scenario: would it solve your case if DotnetPackaging automatically detected executable files included in the bundle and ensured they get executable permissions automatically?

I’m asking because that would keep the tool simple (high-level behavior) without introducing a fully generic custom file mapping/destination system.

If that would work for you, feel free to share a small concrete example (which files are included, and what permissions you expect). That would help a lot when evaluating this for a future improvement.

[claunia]

To be precise this is what ArchLinux package script does:

# Install MIME database file
    cd "${srcdir}"/"${_aarubase}"
    install -d -m0755 -g 0 "${pkgdir}"/usr/share/mime/packages
    install -m0644 -g 0 -t "${pkgdir}"/usr/share/mime/packages aaruformat.xml

    # Install desktop file
    install -d -m0755 -g 0 "${pkgdir}"/usr/share/applications
    install -m0644 -g 0 -t "${pkgdir}"/usr/share/applications aaru.desktop

    # Install icons
    cd "${srcdir}"
    install -d -m0755 -g 0 "${pkgdir}"/usr/share/icons/hicolor/32x32/apps
    install -m0644 -g 0 -t "${pkgdir}"/usr/share/icons/hicolor/32x32/apps icons/32x32/aaru.png

    install -d -m0755 -g 0 "${pkgdir}"/usr/share/icons/hicolor/64x64/apps
    install -m0644 -g 0 -t "${pkgdir}"/usr/share/icons/hicolor/64x64/apps icons/64x64/aaru.png

    install -d -m0755 -g 0 "${pkgdir}"/usr/share/icons/hicolor/128x128/apps
    install -m0644 -g 0 -t "${pkgdir}"/usr/share/icons/hicolor/128x128/apps icons/128x128/aaru.png

    install -d -m0755 -g 0 "${pkgdir}"/usr/share/icons/hicolor/256x256/apps
    install -m0644 -g 0 -t "${pkgdir}"/usr/share/icons/hicolor/256x256/apps icons/256x256/aaru.png

    install -d -m0755 -g 0 "${pkgdir}"/usr/share/icons/hicolor/512x512/apps
    install -m0644 -g 0 -t "${pkgdir}"/usr/share/icons/hicolor/512x512/apps icons/512x512/aaru.png

    cd "${srcdir}"/"${_aarubase}"/bin/Release/${_netcoretarget}/${dotnet_rid}/publish

    # Create destination directory
    install -d -m0755 -g 0 "${pkgdir}"/opt/Aaru

    # Copy Linux binary
    install -m0755 -g 0 -t "${pkgdir}"/opt/Aaru aaru

    cd "${srcdir}"/"${_aarubase}"/bin/Release/${_netcoretarget}/${dotnet_rid}

    # Copy documentation files
    install -m0644 -g 0 -t "${pkgdir}"/opt/Aaru *.md
    install -m0644 -g 0 -t "${pkgdir}"/opt/Aaru LICENSE*

    # Link executable
    install -d -m0755 -g 0 "${pkgdir}"/usr/bin
    ln -sf /opt/Aaru/aaru "${pkgdir}"/usr/bin/aaru

TLDR:
Copies the MIME declaration to the XDG directory.
Copies the desktop file to the XDG directory.
Copies several sizes of the icon to the corresponding XDG directories.
Copies the binary to /opt/Aaru (as expected by Arch Linux specifications)
Copies the documentation and license to /opt/Aaru
Links the binary to /usr/bin

If my memory doesn't fail Debian asks packages to copy their license to a specific directory as well. (Arch doesn't, have to take a look about Fedora/RedHat requirements about that).

I would need both formats and the ability to specify different locations for them (as said, Debian requirements are not RedHat's), or a single location for both.

Right now I have created a classic debian/redhat traditional packaging system and can keep using it but I would prefer something more .net-y.

Also there is some package that insists in creating some "BuildHost-4.x" directories that mean nothing, do nothing, have nothing to do with my executable, but appear in the publish folder just because, that I do not want packaged. Apparently is some known issue with a dotnet dependency with no known solution atm.