#182 tarball created from unpacked source SCM repo has wrong name in the path
Closed 5 years ago Opened 6 years ago by brianjmurrell.

https://github.com/clime/blog-tutorial-flat-unpacked says:

the sources are kept as developer made them and they will be packed into the tarball named after 'Source0'

But as you can see in this build the source was unpacked as:

Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.i5ayfj
drwxrwxr-x mockbuilder/mockbuilder 0 2017-12-09 02:43 python-iml-agent-4.0.0.1/
-rw-rw-r-- mockbuilder/mockbuilder 1158 2017-12-09 02:43 python-iml-agent-4.0.0.1/setup.py
-rw-rw-r-- mockbuilder/mockbuilder 5323 2017-12-09 02:43 python-iml-agent-4.0.0.1/python-iml-agent.spec
-rw-rw-r-- mockbuilder/mockbuilder   85 2017-12-09 02:43 python-iml-agent-4.0.0.1/logrotate.cfg
-rw-rw-r-- mockbuilder/mockbuilder   95 2017-12-09 02:43 python-iml-agent-4.0.0.1/README.txt
-rw-rw-r-- mockbuilder/mockbuilder  149 2017-12-09 02:43 python-iml-agent-4.0.0.1/requirements.txt
...

with python-iml-agent-4.0.0.1 being the directory it was packed under. But the Source0 tag though points at https://pypi.python.org/packages/source/i/iml-agent/iml-agent-%{version}.tar.gz (after macro evaluation).

Shouldn't the source have been packed under the directory name iml-agent-4.0.0.1 per the Source0 tag in the specfile?


Tarball will be named iml-agent-%{version}.tar.gz according to Source0. What's inside will always be %{name}-%{version}, which is what %setup -q expects.

What's inside will always be %{name}-%{version}, which is what %setup -q expects.

Not always. Particularly with python modules. The specfile for a randomly chosen one demonstrates. So does this one again chosen at random.

It also needs to be said that it's not an option to change the specfile's %[auto]setup to expect the tarball to unpack into python-iml-agent-<version> since that would break use of the specfile outside of this source repo, where it would be expected to fetch Source0 from the Pypi registry and it would unpack that as iml-agent-<version> not python-iml-agent-<version>.

it seems that direction really needs to be taken from the %[auto]setup macro as to where it's going to be expecting the source to be. I'm not sure how feasible that is though without writing some custom specfile parsing code.

What's inside will always be %{name}-%{version}, which is what %setup -q expects.

Not always. Particularly with python modules. The specfile for a randomly chosen one demonstrates. So does this one again chosen at random.

Right, because they are using -n %{srcname}-%{version}. I was talking only about bare%setup -q.

It also needs to be said that it's not an option to change the specfile's %[auto]setup to expect the tarball to unpack into python-iml-agent-<version> since that would break use of the specfile outside of this source repo, where it would be expected to fetch Source0 from the Pypi registry and it would unpack that as iml-agent-<version> not python-iml-agent-<version>.
it seems that direction really needs to be taken from the %[auto]setup macro as to where it's going to be expecting the source to be. I'm not sure how feasible that is though without writing some custom specfile parsing code.

I recommend having two spec files for such case, one for development and one for actual production use in such a case. I don't have much other ideas here.

Right, because they are using -n %{srcname}-%{version}. I was talking only about bare%setup -q

Yes, I understand that. But that's how the spec is written and there are lots of specs written this way. The Fedora Python packaging guidelines even council doing it this way in the example spec file in the aforementioned page:

%prep
%autosetup -n %{srcname}-%{version}

I recommend having two spec files for such case, one for development and one for actual production use in such a case.

This is not a solution unfortunately because this is not an issue of needing different specs for production and development. This is a case where Copr is not utilizing the production spec correctly.

I don't have much other ideas here.

As a rough example for a potential solution:

$ rpmspec -P python-iml-agent.spec | sed -nre '/%(auto)?setup .*-n/s/.* -n ([^ ]*).*/\1/p'
iml-agent-4.0.0.1

Right, because they are using -n %{srcname}-%{version}. I was talking only about bare%setup -q

Yes, I understand that. But that's how the spec is written and there are lots of specs written this way. The Fedora Python packaging guidelines even council doing it this way in the example spec file in the aforementioned page:
%prep
%autosetup -n %{srcname}-%{version}

I recommend having two spec files for such case, one for development and one for actual production use in such a case.

This is not a solution unfortunately because this is not an issue of needing different specs for production and development. This is a case where Copr is not utilizing the production spec correctly.

Well, COPR (rpkg) simply does not work for this set of existing .spec files when one would want to use with unpacked sources.

I don't have much other ideas here.

As a rough example for a potential solution:
$ rpmspec -P python-iml-agent.spec | sed -nre '/%(auto)?setup .-n/s/. -n ([^ ])./\1/p'
iml-agent-4.0.0.1

Yes, I understand you can do something like that but instead of using %autosetup or %setup macro you can also opt for using a lua scriplet or shell expansion ($()) to do the prep phase and then there is basically no way to parse out the expected name of the directory in the dynamically created tarball. This is kind of limit of this approach and I don't think we can do it so that it can be universally applied on any existing .spec placed together with its unpacked sources.

OK. I won't press it. This is not a use-case I really care about anyway. Once #183 is implemented this one becomes moot for me.

I just thought I would file as it was something I came across as I was trying to work out a work-around to #183.

Hello, rpkg now contains set of macros that you can place into a spec file and that will do the packing. They also offer dir_name param with which you can alter dir name inside the the tarball.
The macros are:

{{{ git_pack }}}, {{{ git_dir_pack }}}, {{{ git_cwd_pack }}}, {{{ git_archive }}}, {{{ git_dir_archive }}}, {{{ git_cwd_archive }}}

The previous auto_packing functionality that caused the problems have been deprecated.

This doesn't completely address this issue. In case, there is:

Source0: https://pypi.python.org/packages/source/i/iml-agent/iml-agent-%{version}.tar.gz

no action will be taking by rpkg (with auto_pack=False, which is default). Instead, the sources will be downloaded from net if %_disable_source_fetch rpm macro is zero. We took a fully explicit approach to "auto_packing" (you need to say it by the macro), which means it's not possible to use the spec file for packed as well as unpacked use-case unless you create rpkg macros that can do that and use them in the spec file.

Metadata Update from @clime:
- Issue status updated to: Closed (was: Open)

5 years ago

Login to comment on this ticket.

Metadata