Support RPM filetypes

[djgilcrease]

in https://github.com/goreleaser/nfpm there is the need to support at least the ConfigFile type https://github.com/sassoftware/go-rpmutils/blob/master/tags.go#L138 because when you uninstall a rpm by default a *.rpmsave file is created for all config files which nfpm verifies as part of it's testing.

Support for this was initially added as #16 but was asked to create an issue around this to determine if and how to support this for the tar2rpm tool

My initial idea was to not support it for the tool, and only for the case where rpmpack is being used as a library. Another option is to provide flags to point to a tar of each filetype. The final option I can think of is to have an option like -config-file=path/to/config/file that would have to match h.Name in https://github.com/google/rpmpack/blob/master/tar.go#L62 to set the file type

Of the 3 options I am personally leaning toward the latter so the command would look something like tar2rpm -config-file etc/bla.conf -config-file etc/bla/overide.conf -file bla.rpm bla.tar which makes it so you do not need to separately tar up each type of file. We would want to ensure wildcard support for this so you could do -config-file etc/*

Open Question: which file types do we want to support from the tool?

• ConfigFile
• DocFile
• IconFile
• MissingFile
• NoReplaceFile
• SpecFile
• GhostFile
• LicenceFile
• ReadmeFile
• ExcludeFile
• UnpatchedFile
• PubKeyFile
• PolicyFile

I know ConfigFile for sure as the need for that prompted adding this feature. I would also say DocFile, LicenceFile, ReadmeFile

[jarondl]

General comments about option 3:
At first I thought the cli tool (rpmpack) should accept filenames.
But then I started thinking really hard about the API of file ownership, group, and permission bits. Most rpms have files owned by root, but obviously we cannot copy the ownership from existing files, because builders will not use root. So I went to the man pages of tar(1) to see what they did, and started to think about re-implementing all of that functionality. This wasn't easy. Only then it hit me! Why re-implement tar, if we can use tar itself.
This is how the cli tool got its better name, tar2rpm and its much simpler interface.

So no, I don't want to specify files by name in flags, or implement globs etc.

For now I think the cleanest interface is multiple tar files, one per type, but I am not sure about it.

Let's start with option 1, implementing it only in the library, with an eye to multiple tar files in the future.

[djgilcrease]

Sounds good to me and makes sense.

[jarondl]

I am reopening this bug to track the parts #23 did not cover: cli and bzl.

[chris-rock]

@djgilcrease I think the support for NoReplaceFile (especially via goreleaser and nfpm) would be neat since this would allow you to write a package that ships with a default config. Updates would not replace the config then. What do you think?

[djgilcrease]

I like this idea and have been thinking about how to add it to nfpm/goreleaser

[flowchartsman]

Original Comment

Don't know if this issue is dead or not, but just dropping in to say that GhostFile and NoReplaceFile are also important. GhostFile for logging/state directories for services in the standard locations, and NoReplaceFile for any configuration templates an RPM might ship with that are intended to be filled in by the user to prevent them being overwritten by an upgrade. Not sure if that's included in ConfigFile support on its own or not. Will look into it and update the issue if so, but if anyone knows better, feel free to chime in.

EDIT: It appears that #23 has already been merged for some time, and this issue only remains open to track cli/bazel integration. Mea culpa, I should have read the thread more closely.