Various problems with the .Files map

[thomasf]

trafficstars

1. Directories are not included in the archive

I was just using the Files map to add in extra files..

...Files = map[string]string{
  "somefile":"/usr/share/doc/someproject/somefile",
}

This fails because the directory /usr/share/doc/someproject/ isn't explicitly added to the archive.

2. Directories are not supported in the Files map

Files should probably also support directories which would be added recursively.

3. It's not possible to add a source file multiple times

The mapping in the Files map should be inverted to support copying one source file to multiple destination files. The current Files map map[src]dst makes it impossible to reuse src multiple times.

I had an actual use case for this today when I tried to put a default configuration file both in /etc and in the documentation folder.

good solution ⊂(◉‿◉)つ

A backwards compatible solution is keep the Files struct field (map[src]dst) and add a new field Include which probably is some functionality to properly handle sources and destinations. It opens up for .Exclude or .Filters fields. I will work on a suggestion.

worse solution ◔_◔

A worse solution is to change Files from map[src]dst to map[src][]dst which breaks the current API so that any current users have to change.

worst! solution ಠ_ಠ

The worst solution is to just silently change map[src]dst to map[dst]src which will cause errors without breaking compilation.

[thomasf]

I won't start working on fixes for any of these items before we have had a discussion about it since item 2 and 3 probably will need a lot of changes which is pointless work until we have an agreement on exactly what should be done.

Btw. I'm creating a plugin for deb Drone CI right now and trying it out in a small number of build configurations which is why I'm bumping in to issues here and there atm. https://github.com/thomasf/drone-deb/

[thomasf]

@cbednarski would you be ok with breaking the Go API a bit as long as the command line client and it's json file continues to work as before?

I need to finish up https://github.com/thomasf/drone-deb/ within a couple of days, it's currently unusuable for what I'm trying to package due to bugs with files handling..

[thomasf]

After working on a couple of prototypes for how to change files in general it always ended up with implementing some virtual file sytstem-like functionality... So yesteray I looked at the VFS packages which are available for Go and the one in godoc was almost a match except for the few things which are specific to what godoc needs.. So I have forked it and started adding what I need to integrate with mkdeb.. https://github.com/thomasf/vfs ..

When using vfs namespaces to assemble the control/data trees most of the buggy and hard to follow filepath/normalize/ related code spread out over too many places in packatge.go can be replaced by having a vfs namespace for the control and one for the data archive.

[thomasf]

Soo.. I will probably rip out most logic from the current PackageSpec and create individual functions or structs for the various archive types.. PackageSpec kan be kept for compatibilty..

I will begin to try to use something like this in package.go (I think I just finished the work on vfs, so just eperimenting a little bit here)

[thomasf]

If possible I will avoid to expose the vfs package to consumers of the new deb package APIs