Install bdcs.rpm from Copr instead of pulling it from S3

[atodorov]

Note: the failure in test_images.sh is from the command:

./dist/build/bdcs-cli/bdcs-cli --url http://api:4000/ -m metadata.db -r metadata.repo/ compose tar http-server
Creating tar of http-server, saving to http-server.tar
bdcs-cli: export: rawSystem: runInteractiveProcess: exec: does not exist (No such file or directory)

which looks like it can't find bdcs-export.

[atodorov]

The original error reported is weldr/bdcs#143 which however doesn't seem to be a problem for Jenkins.

The current failure is:
"Unable to add /usr/lib64/libnssckbi.so, file already added at this location"

where this file is a symlink to /etc/alternatives/ so I'm not quire certain that is going on.

[bcl]

Looks ok. Note that we're going to start using the new compose code in bdcs-api soon, so don't worry about export.

[atodorov]

"Unable to add /usr/lib64/libnssckbi.so, file already added at this location"

@wgwoods ^^^ this one sounds related to your work on /etc/alternatives, indeed this file is a symlink to /etc/alternatives. How do you propose I deal with this failure:

1. Remove the offending package from the recipe so it's not exported
2. Something else ?

[wgwoods]

(Paraphrasing what I said on IRC, for the record)

In the long term: we're going to have to get everyone who's using /usr/sbin/alternatives in their package's %post to convert over to using a config file or something so that we can parse those and figure out which link has the highest priority. (See fedora-sysv/chkconfig#9 where I've proposed a config file format to upstream).

In the near-term I think we're gonna need a couple of things:

1. Find some way to store the fact that %ghost files (like links to /etc/alternatives items) aren't actually in the content store and need to be generated at export-time
2. Start compiling /etc/alternatives data somewhere (possibly just start writing our own /etc/alternatives.conf.d files?) so we have some way to look up the target and priority for each possible alternative
3. Use that data to resolve these conflicts and generate the correct link

This is a specific case of a general problem - "how do we handle files that need to be generated at export-time?" - and it's gonna take some time to design a sensible long-term solution. Alas, I'd hoped this day wouldn't come so soon...

[atodorov]

Note: if this fails we have to merge it after #33 so we don't have to adjust the recipes inside the Rust API docker image.

[bcl]

I'm really opposed to these kinds of changes. This is being changed purely to get tests to pass, not to fix an actual problem. We should not be doing that.

I think that @dashea has fixed the symlink problem in bdcs so this should not be needed.

[bcl]

This piece of code is going to go away in the next iteration, it'll be using the API to start the compose, not calling bdcs commands directly.

[bcl]

Drop the Commands.hs and http-server.toml commits and everything else looks ok to me.