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 -
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
