Subsequent invocations would fail with an error about a corrupted file.
We don't have support for resuming a failed download, so let's remove the
partial download results.
"/" is deprecated everywhere, so warn about that.
Translation from SPDX is only used for fedora or epel targets.
The Fedora license list coalesces various license variants that have different
SPDX license tags into a single license tag. Most notably, this is done for the
39 BSD variants and 18 MIT variants on the Fedora good licenses list. When a
spdx→fedora mapping exists, it should always be unambiguous, because SPDX
considers any change in the license text to be a unique license, and Fedora is
more permissive in that regard.
To make a review of the translation easy, debug info is output to stdout, and
comments are inserted into the spec when some translation is required or when
there are problems with the upstream licensing.
The license list is pulled from the spdx project:
$ curl 'https://docs.google.com/spreadsheets/d/1LUJuzGKC5K2yYuAg8S-2VYbS2dmg_4IlFdpqj7n9Ghg/export?format=csv&id=1LUJuzGKC5K2yYuAg8S-2VYbS2dmg_4IlFdpqj7n9Ghg&gid=138634715' > rust2rpm/spdx_to_fedora.csv
v2:
- apply "/" replacement always
v3:
- print to stderr
- use csv.DictReader
- filter out empty license lines
This is needed to support the rust2rpm OBS source service.
Merges: https://pagure.io/fedora-rust/rust2rpm/pull-request/52
Signed-off-by: Neal Gompa <ngompa13@gmail.com>
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
When a file unpacked from a crate is edited, it is OK to edit it
directly. But when editing something that was already there, we should
make a temporary copy. Let's do this copy next to the file being
edited, so it's easy for the user to open related files.
This adds the possibility to generate the spec file from a rust project
checkout, by specifying either the toml file or just the directory name, without
having a crate at all. This is nice when developing local projects and tweaking
the metadata. The expected way to use this is 'rust2rpm .../project/', look at
the generated spec file, do fixes to source, regenerate spec file, etc.
$ rust2rpm -t fedora --stdout .
(when testing)
or
$ rust2rpm -t fedora /path/to/project
(in the dist-git directory)
Only args that contain "/" are considered local arguments. An special exception
is made for "." and "..", since that's likely to be a common use case and cannot
be mistaken for a remote crate name.
When --patch is used, the filename is changed from name-version-fix-metadata.diff
to name-fix-metadata.diff. This seems more useful, because after the crate
version is updated, the patch file would either stay the same or would just need
to be rebased, and it is not tied to the crate version.
The crate packaging spec file template has been split out into its own file,
and various distro specific modifications to the spec are incorporated as
include files that are conditionally applied based on the target.
Merges: https://pagure.io/fedora-rust/rust2rpm/pull-request/46
Signed-off-by: Neal Gompa <ngompa13@gmail.com>
That way we don't need to pull any python/whatever stuff from rust itself.
Closes: https://pagure.io/fedora-rust/rust2rpm/issue/30
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
Even we don't have epel support at this point, it should be same
as fedora. It doesn't make any sense to rely on target names in
templating.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
Those are not completely build-time since we ship source code. We
do need those dependencies to do builds afterwards.
Also use private members to not copy lists.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
Imagine, that:
* A requires 0.6.0 <= X < 0.7.0
* B requires 0.9.0 <= X < 0.10.0
* C requires A and B
If we use Requires + Conflicts, then we just can't build or install
C, because sub-dependencies are conflicting between each other.
Proper syntax is: (X >= 0.6.0 with X < 0.7.0)
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
We need to know things like name of package in order to create
properly named spec file.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
New cargo exposes description, so we can even generate summary out
of it.
We will need to do some pre-processing in future, but good enough for
the beginning.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>