On Wed, 2006-07-12 at 15:18 -0400, Fernando Nasser wrote:
> Jesse Keating wrote:
> > On Wednesday 12 July 2006 10:08, Nicolas Mailhot wrote:
> >
> >> Probably depends on how often the packages are forked and rebased, and the
> >> amount of changes you do above the original packaging
> >>
> >> It'd be great to have a common naming convention when stacked packaging
> >> happens though
> >>
> >
> > Why though? What real problem does it actually solve?
> >
> >
>
> Several reasons.
>
> First, as these packages are maintained upstream (not only the software,
> but the spec files and other SRPM bits) it is important to know in which
> EVR they are based on. So, if you know that ......6jpp has a fix for
> some problem then if the one you have installed is .....6jpp<some fedora
> suffix) also has it. That is what Nicholas was talking about.
IMHO, this tracking belongs in the upstream versioning, NOT the
packaging Release field. This is how every single other OSS package
handles it. That's how I know if httpd has a feature in 2.2.1 that isn't
in 2.2.0, or if a bug fix is in 2.2.2.
> Second, these packages are supposed to interoperate with other
> repositories (remember that only a fraction of Java packages is AOT
> built on Fedora), so preserving the upstream EVR string is fundamental
> for that to work. This ensure no packages are unduly overwritten when
> the two repositories are enabled and that the latest version/releases
> prevail.
Again, if upstream would use the version as it is intended, this would
be a non-issue. Packages could depend on foo = %{version}
> All Java releases for RHEL have been done this way, by adding _NNrh to
> whatever the upstream JPackage EVR was with success.
> For Fedora 3 and Fedora package a _NNfc was adopted. Gary Benson used
> to have a document describing it, which I thought lived in Fedora pages
> somewhere.
>
> There are hundreds of Java packages there, all rebuilt from upstream
> JPackage.org, shipped on Fedora for a couple of years with this EVR
> convention.
Perhaps its time to revisit this. Yes, it will be painful, but the way
that these packages are named is painful.
> W.r.t. the suffix added after the upstream EVR it does not really
> matter.
If this is indeed the case, lets drop it altogether. Adding this suffix
(and the jpp naming) is merely going to cause rpm confusion down the
road. Especially if every repo that is supposed to be interoperable with
the same set of packages is using a different suffix.
I'm really going to stand firm on this one, and unless I'm outvoted in
the Fedora Packaging Committee, I don't see us permitting this JPackage
naming scheme.
~spot
--
Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!
