@redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> That is only used for passthrough publication afaik. If you
>>>>>>>>>>> publish each content unit "by hand", you create a new relative path
>>
gt;>> can be published.
>>>>>>>>>>
>>>>>>>>>> On Tue, Apr 28, 2020 at 4:09 PM Daniel Alley
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>&g
t;>> information in
>>>>>>>>>> a field on RepositoryContent would not be possible.
>>>>>>>>>>
>>>>>>>>>> On Mon, Apr 27, 2020 at 6:08 PM Daniel Alley
>>>>>>>>>>
w
>>>>>>>>>> (Tuesday April 28th) at 13:30 UTC (please convert to your local
>>>>>>>>>> time).
>>>>>>>>>> https://meet.google.com/scy-csbx-qiu
>>>>>>>>>>
>>>>>
t;>>>>
>>>>>>>>> On Sat, Apr 25, 2020 at 7:02 AM David Davis
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I had a chance to think about this some more yesterday and wanted
>>&
n plugin writers so I thought of a couple
>>>>>>>>> alternatives:
>>>>>>>>>
>>>>>>>>> First, we could add a relative_path field to RepositoryContent
>>>>>>>>> instead of moving it there. This
>>>>>>>> the
>>>>>>>> relative_path field on ContentArtifact. But plugins could use this
>>>>>>>> optional
>>>>>>>> field to store relative paths per rep
use this
>>>>>>> optional
>>>>>>> field to store relative paths per repository and then use this field
>>>>>>> when
>>>>>>> generating publications.
>>>>>>>
>>>>>>> The secon
solve this in
>>>>>> pulpcore. RPM would create its own object that would map content in a
>>>>>> repository to relative_paths.
>>>>>>
>>>>>> David
>>>>>>
>>>>>>
>&g
gt;>> relative_paths.
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>> On Tue, Apr 21, 2020 at 9:22 AM Quirin Pamp wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>
ative_path around sounds slightly scary with the potential to
>>>>> break things.
>>>>>
>>>>>
>>>>> As such, I would be interested to be kept in the loop as this moves
>>>>> forward. (Mailing list once there is some movement is e
o break
>>>> things.
>>>>
>>>>
>>>> As such, I would be interested to be kept in the loop as this moves
>>>> forward. (Mailing list once there is some movement is entirely sufficient
>>>> )
>>>>
>>>>
>
g list once there is some movement is entirely sufficient
>>> )
>>>
>>>
>>> Thanks,
>>>
>>> Quirin Pamp
>>> --
>>> *From:* pulp-dev-boun...@redhat.com on
>>> behalf of Ina Panova
>>
ted to be kept in the loop as this moves
>> forward. (Mailing list once there is some movement is entirely sufficient
>> )
>>
>>
>> Thanks,
>>
>> Quirin Pamp
>> ------
>> *From:* pulp-dev-boun...@redhat.com on
>> b
sufficient )
Thanks,
Quirin Pamp
From: pulp-dev-boun...@redhat.com on behalf of
Ina Panova
Sent: 21 April 2020 14:07:13
To: Daniel Alley
Cc: Pulp-dev
Subject: Re: [Pulp-dev] the "relative path" problem
Daniel,
how about setting up a meeting and
Daniel,
how about setting up a meeting and brainstorm the alternatives, pros/cons
there?
Regards,
Ina Panova
Senior Software Engineer| Pulp| Red Hat Inc.
"Do not go where the path may lead,
go instead where there is no path and leave a trail."
On Fri, Apr 17, 2020 at 5:57 PM
Bump, this item needs to move forwards soon. Does anyone have any thoughts?
On Wed, Apr 1, 2020 at 9:40 AM Pavel Picka wrote:
> Hi,
> I'd like to add one more question to this topic. Do you think it is a
> blocker for PRs [0] & [1] as by testing [2] this features I haven't run
> into real
Hi,
I'd like to add one more question to this topic. Do you think it is a
blocker for PRs [0] & [1] as by testing [2] this features I haven't run
into real world example where two really same name packages appears.
I think this is a 'must have' feature but until we solve/decide it we can
have two
18 matches
Mail list logo
