Conflicts Draft Proposal Round 2
by Tom Callaway
As discussed in today's FPC meeting, I've made some changes to the
Conflicts Draft Proposal to document some acceptable cases, add some
additional valid file name conflict workarounds, and fix the wording
here and there.
FPC Members: Please vote on this draft via email, so we can get this in
place well before the Core/Extras merge. As I wrote the draft, I vote
+1. ;)
http://fedoraproject.org/wiki/PackagingDrafts/Conflicts
Thanks,
~spot
17 years, 3 months
Upstream sources that contain binaries
by Matt Wringe
Hi,
What is the proper way to handle upstream source tars that also contain
binary dependencies? This is very common with java packages.
Sorry if this is already covered in the guidelines, I couldn't find this
case mentioned anywhere.
Should the binaries be removed from the source tar and create a new
binary-less tar. This method has been used in the past, resulting in new
tars with -RHCLEAN added to the end of their names.
Or should the tar just be left alone, and have the a script inside the
spec scrub out the binaries?
According to the Review Guidelines:
"The sources used to build the package must match the upstream source,
as provided in the spec URL. Reviewers should use md5sum for this task."
(http://fedoraproject.org/wiki/Packaging/ReviewGuidelines)
Thanks,
Matt Wringe
17 years, 3 months
LibtoolArchives, v0.3
by Rex Dieter
http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives
Motivation
(AFAICT) The intent of the original guideline was to avoid problematic
libtool archives1, those used in linking, not necessarily those used for
loadable modules, plugins, etc...
While .la files outside of $LD_LIBRARY_PATH SHOULD be ok to omit,
(AFAIK) keeping them causes no harm either, so shouldn't be a MUST to
remove. Problem is, there are quite a few software packages that require
.la files for proper function (including some kde bits, though this is
being worked on).
Comments?
-- Rex
17 years, 3 months
DesktopFiles proposal
by Rex Dieter
http://fedoraproject.org/wiki/PackagingDrafts/DesktopFiles
Motivations for updating the existing guideline:
* reference desktop-entry-spec, including adding a SHOULD/MUST to
comply with it.
* Make it clear usage of desktop-file-install is not mandatory, but
only required if you need to manually manipulate apps' .desktop file or
to install a previously lacking one.
* update examples:
mention --add-category/--remove-category
modify an already-installed .desktop file (e.g. moving it from
%_datadir/applnk/<foo>/ to %{_datadir}/applications )
17 years, 3 months
Missing todays meeting
by Ralf Corsepius
Hi,
Due to other obligations, I'll probably be missing today's FPC meeting.
Ralf
17 years, 3 months
Java (jpackage) naming scheme rehash -- part 1 Goals
by Fernando Nasser
Hi all,
At Jesse's request, I took a look at the Wiki page in
http://fedoraproject.org/wiki/PackagingDrafts/JavaPackageNaming
"Naming Conventions for Packages Adapted from JPackage"
Of course, some time has passed and things have already evolved, so I
will try and update the text. Please comment and lets see how we should
update the Wiki page.
1) Problem Space
"Many Java programs are first packaged by the [WWW] jpackage project. In
essence, the Fedora packages have two upstreams: The upstream project
itself and the jpackage project's spec file and patches. Fedora imports
a package from jpackage and makes changes to enable native AOT
compilation via gcj and bugfixes that have not been merged into either
of the upstreams."
> Well, The last sentence is no longer true. The AOT compilation bits
were propagated upstream, so all the Java team has to do now is to
import the upstram package as is and build. We still need to make any
changes to the code to circumvent GCJ shortcomes, but these are so rare
nowadays that almost all packages build without any changes at all.
> As a consequence, fixes have been made on the usptream version, which
is them re-imported, and we've been also reimporting when fixes are
applied upstream comming from the other JPackage-based distros or from
direct JPackage users feedback.
"Presently, Core's jpackage-based packages have reflected the package
origin within the package Release: 1jpp_2fc In this scheme, the 1jpp is
the upstream jpackage release, _ is a separator, and 2fc is the Fedora
release. (Note, this scheme is not currently as defined as the Fedora
Naming Guidelines. So there are some practices above the base standard
that would need to change.) This scheme has two expressed goals:"
> OK, here we have made much progress:
a. The "_" character has been removed and replaced by a '.'
b. The "fc" string has been removed
c. All FC6 packages have been rebuilt to comply with a and b above
d. An initial agreement has been reached to also compatibilize the
pre-release cases, with JPackage adopting a Fedora-like order.
> Summary: It all comes down now to the remaining ".NNjpp" in the
release which indicates the upstream version that was last imported
(sync point you could call it).
In the case of the goals, I think the original ones in the week were not
correct in the first place. Lets try again:
" 1. Allow for upgrading between the Fedora and JPackage repositories
so that upgrade paths similar to the following works:
*
java-foo-1.0-1jpp_2fc [Fedora Release]
java-foo-1.0-2jpp [Updated JPackage Release]
java-foo-1.0-2jpp_3fc [Updated Fedora Release rebased
against the new JPackage]
3. A third expressed goal that conflicts with 1. is to upgrade
Fedora packages only with Fedora packages and jpackage packages with
jpackage packages."
> These two goals can be made into a single one, lets say: "flexible
upgrade paths".
> There is no conflict whatsoever -- we currently do all these:
a. Both Fedora and JPackage (what is stated in 1, i.e., newest release
globally) by leaving all repos enabled (both fedora-core and jpackage)
b. Fedora only by disabling the jpackage.repo
c. JPackage only by using --exclude=*jpp* --excluce=eclipse* when
upgrading from fedora-core.repo and enabling only the jpackage.repo for
the Java packages update (people play with --enablerepo for that management)
"2. Allow users and packagers to tell what JPackage release the
java package was based against."
> This is very important to us (Java team). We can quickly identify if
the version we have already has a fix or not, among other things.
I will have to add a goal that was not stated in the initial Wiki, lets
call it 4:
"4. Allow the switching of Java stacks as a whole"
> This is currently accomplished by using regular expressions based on
the *jpp* and eclipse* patterns.
> This is useful for development so we can try sets of packages built
with a different compiler for instance, without having to change all
spec files to bump releases, and to revert the system to the original
state afterwards. We use this a lot.
> There are also users that want to switch the collection of Java
packages to use a set compiled with a proprietary JDK for instance
(maybe a different version of Java), or something provided by the
software vendor of some major component they bought.
OK, now the Wiki page states:
"Which naming guideline is chosen depends in large part on whether these
are judged to be worthwhile and attainable goals."
> Which I think is correct.
Discussion of the goals
"Goal #1
If JPackage were truly an upstream then we wouldn't want users to
upgrade Fedora Packages with JPackage. We have bugfixes, local changes,
and other patches that we add to packages to make them work better on
Fedora. Having users upgrade between upstream and our packages is not a
goal with any other upstream. gbenson states this [WWW] here although he
phrases it in the specifics of Fedora/JPackage instead of the general
Fedora/Upstream."
> We don't do anything to make packages run better on Fedora. We do
pre-compilation, which does help in the startup time. But there is no
real harm in revert to a bytecode-only package to get an upstream fix
until it shows up in pre-compiled form in a Fedora update.
"There could be times when the jpackage naming is not compliant in the
name, version, or release fields. When this happens, we would not be
able to attain this goal. For instance:
cryptix-asn1-20011119-4jpp_2fc.1.1.src.rpm. The version field must be
changed before importing otherwise the final release of cryptix-asn1-1.0
will not upgrade the package."
> That was a wrongly versioned package from an older JPackage release.
The maintainer was informed and the problem was fixed. It is now
cryptix-3.2.0-9jpp. In general, we have had no problems in getting this
kind of things fixed. I think this comment can be removed.
"Goal #3
This is not truly implementable via the package release tag.
Separating the native libraries into a subpackage might have some
bearing on this."
> Yes it is implementable, as shown above.
"Goal #2
Users shouldn't need this information. The Fedora Package may have more
fixes than the JPackage one. It may be synced with more upstream
bugfixes. It may contain snapshots of JPackage work that haven't hit the
repositories yet because JPackage is working on a new major release. If
the package works without bugs then the end user is happy."
> Putting a set of compatible packages together is a major endeavor.
The Java team, as well as the folks from Mandriva and Suse have been
basically polishing the sets that have been created upstream.
> Also, we make the fixes/changes upstream first, then import. This
way we benefit from feedback from people (both packages and Java users)
who know deeply some of these Java software libraries.
> Again: updating paths are optional, and it is up to the user to
choose. The current naming only allows that to be done if so desired,
which would be otherwise not possible.
"Developers can use this information. But they aren't going to be
staring at the package name most of the time. When they checkout from
cvs, they'll have a spec file, not an RPM so the filename is no help.
They have to look inside the spec file at which point it's just as easy
to put the information in the %description, a Provides, or a comment.
Using a Provides makes it queryable from the rpm command line as well."
> The way we do now is by "rpm -qa | grep jpp" and variations. Or
similar pattern usage in the repos. We don't need to look inside the
spec file to know that the base for that release was a specific upstream
release.
> Using things like "Provides" for things that are not their original
goal would be abusing that feature, and the information for that is used
by depsolvers and such. We should stay away from that. In a lesser
degree, maintaining a release in the description is not convenient and
error prone, and does not address the other goals anyway.
The Wiki page then has some proposals, which I would prefer to discuss
each one separately once we agree on the goals.
Regards to all,
Fernando
17 years, 3 months
Re: [Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals
by Nicolas Mailhot
Le Ven 12 janvier 2007 05:25, Toshio Kuratomi a écrit :
> Not every upstream agrees with the
> downstream. Not every upstream has the same time frame for updates as
> downstream. We will carry local patches and changes at some point.
Fernando for example is part of the jpackage commiters. He can get fixes
upstream fast (as long as they're actual fixes, not quick hacks that break
other java packages).
The number of jpackage commiters is small, they trust each other, you
don't have the long Fedora procedures designed to get occasional packagers
in line. Fedora won't have to wait for JPP, most often JPP will have to
wait for changes to propagate @fedora
Regards,
--
Nicolas Mailhot
17 years, 3 months
Conflicts Draft Proposal
by Tom Callaway
I drafted a proposal for when it is ok to use Conflicts: (almost never):
http://fedoraproject.org/wiki/PackagingDrafts/Conflicts
Keep in mind that while it is not stated in the Draft, the kernel is
considered a special case, and I feel strongly that most (if not all) of
its existing Conflicts: will be approved.
Fedora Packaging Committee Members should vote via email on this issue,
as we did not have quorum in the IRC meeting to vote.
~spot
17 years, 3 months
