Incorrect package location in metadata when relative path contains a /

[dkliban]

Version
pulpcore 3.56.1
pulp_rpm 3.27.1

Describe the bug

When I create a package in a repository from an artifact using the following commands, the package is published to the correct location, however, the metadata does not match that location.

pulp rpm repository create --name myrepo --autopublish
pulp rpm distribution create --name myrepo --repository myrepo
curl -o camel-0.1-1.noarch.rpm https://fixtures.pulpproject.org/rpm-signed/camel-0.1-1.noarch.rpm
pulp artifact upload --file camel-0.1-1.noarch.rpm
pulp rpm content create --sha256 db0ebc34f184188d4520b6213f1bafd3ccfec84304eb22d3a0c03fd93575a4eb --repository myrepo --relative-path frostyx/test-pulp-1/camel-0.1-1.noarch.rpm

Package location: http://localhost:5001/pulp/content/default/myrepo/Packages/f/frostyx/test-pulp-1/camel-0.1-1.noarch.rpm

Metadata in primary.xml:

<package type="rpm">
<name>camel</name>
<arch>noarch</arch>
<version epoch="0" ver="0.1" rel="1"/>
<checksum type="sha256" pkgid="YES">db0ebc34f184188d4520b6213f1bafd3ccfec84304eb22d3a0c03fd93575a4eb</checksum>
<summary>A dummy package of camel</summary>
<description>A dummy package of camel</description>
<packager/>
<url>http://tstrachota.fedorapeople.org</url>
<time file="1724691102" build="1331831360"/>
<size package="3087" installed="42" archive="296"/>
<location href="Packages/c/camel-0.1-1.noarch.rpm"/>
<format>
<rpm:license>GPLv2</rpm:license>
<rpm:vendor/>
<rpm:group>Internet/Applications</rpm:group>
<rpm:buildhost>smqe-ws15</rpm:buildhost>
<rpm:sourcerpm>camel-0.1-1.src.rpm</rpm:sourcerpm>
<rpm:header-range start="1520" end="2937"/>
<rpm:provides>
<rpm:entry name="camel" flags="EQ" epoch="0" ver="0.1" rel="1"/>
</rpm:provides>
</format>
</package>

Note that location is "Packages/c/camel-0.1-1.noarch.rpm"

[dralley]

Is there a practical issue here or is it mostly inconsequential?

location_href is something that really should never have been added to our schema at all, it was a mistake. Preferably we would remove it entirely. So my inclination is not to change anything until we can do that.

#2580

[FrostyX]

@dkliban proposed I shouldn't upload RPM packages as artifacts and create content out of them but rather do this in one step. And also to not specify the relative path. Everything works as expected now, so solving or not solving this issue won't affect me.