package, package2, package3 naming-with-version exploit

[Panu Matilainen]

On 03/29/2013 12:02 PM, Tomas Mraz wrote:
> On Thu, 2013-03-28 at 14:43 -0400, James Antill wrote:
>> On Thu, 2013-03-28 at 13:53 +0100, Vít Ondruch wrote:
>>> Dne 28.3.2013 13:30, Jan Zelený napsal(a):
>>>> On 28. 3. 2013 at 12:59:44, Vít Ondruch wrote:
>>>>> Dne 28.3.2013 12:09, Florian Festi napsal(a):
>>>>>> This is done to make life easier for package maintainers.
>>>>> Sorry, you definitely not speak for me! This are just excuses. And I
>>>>> asked already several times to have some way to reliable support
>>>>> multiple version of packages without mangling their names.
>>>> Víťo,
>>>> I certainly understand your frustration, as it comes from talking about this
>>>> topic over and over again. However Ruby community is a *very* special case in
>>>> this regard and I'd like to treat it as such.
>>>>
>>>> If you want, we can start a discussion here. But if we do, let's keep the
>>>> discussion strictly constructive and just about *technical* problems. Let's
>>>> not take this to design level of things, as Ruby and Fedora are two completely
>>>> different worlds that will never be fully compatible by design. Therefore the
>>>> final solution (if there is any) has to be some sort of compromise.
>>>>
>>>> Thanks
>>>> Jan
>>>
>>> My point is: "First step to find technical solution for some issue is
>>> admit that there is some issue".
>>
>>   I agree this is a problem, everyone who knows how Fedora packaging
>> works has said, to you, some variant of:
>>
>>   The technical problem is being able to install multiple versions of a
>> package, and you can do that now (and have been able to for the last 10
>> years).
>>   Here is a long list of technical reasons why your desire to have all
>> the parallel installable versions of "foo" called "foo" is not going to
>> work.
>
> I can imagine only one reason for this desire - so that the user can do
> just "yum install foo" when he just wants the latest version of "foo".
>
> What I can see as a possible solution is the following (whether the
> desire above is really worth implementing it is another question):
> Add a new field to the current NEVR fields called for example Branch.
>
> So you would have a NBEVR.
>
> For rpm and yum the Branch field would be something to be treated as
> part of Name, except situation when 'yum install Name' would just choose
> to install Name-Branch package with highest Branch.
>
> The Fedora packaging infrastructure on the other hand would work with
> Branch rather as part of the version except it would allow having
> multiple packages of the same name but different branch in the
> repositories. The infrastructure would have to also allow both having a
> different git branch in the git repositories for different "package
> branch" and also having different "package branches" built from a single
> git branch.
>
> The question is whether good backwards compatibility can be achieved and
> whether all this work needed to support this is really worth the
> improvements for developers and end users.

This is actually fairly close to what I've suggested: it wouldn't be 
hard to add a little bit of spec syntax sugar to allow specifying a 
"branch" in the spec or even on the command line. Except that in this 
case the spec-level "branch" would just be something thats encoded 
(well, likely appended) to the resulting binary package name(s) and not 
a new concrete tag which rpm, yum and all the related tools will need to 
be very tediously (getting such a thing deployed in Fedora is a 
multi-year process) taught about. When a "branch" is present, rpmbuild 
could add extra provides to allow name-branch and name to work.

That would make things easier for packagers, but be fully compatible 
with all rpm related tools as in the binary-level, nothing actually changes.

	- Panu -