To noarch or arch for arch specific script packages?
by Jesse Keating
There exists packages that are written in say python, but are used for arch
specific task. Consider python scripts that deal with grub (i386/x86_64), or
other such things. Do we want to continue considering these 'noarch'
packages, or do we want to mark them as arch specific? They'll already have
the ExclusiveArch: i386 x86_64 or ExcludeArch in the spec.
The reason I bring this up as it has tickled a possible bug in Brew, Red Hat's
build software. Currently brew will look at BuildArch and ExclusiveArch /
ExcludeArch, and the configured arches for a build target to decide where to
build the package at. In one package case, it has BuildArch: noarch, and
ExclusiveArch: i386 x86_64. Combining the two, brew is complaining that
Architecture is not included 'noarch'. A (ugly) work around was to
add 'noarch' to the ExclusiveArch list, or use ExcludeArch and list a bunch
of arches this package wouldn't work for, but this can break distribution
composes that query ExclusiveArch to figure out what packages should be
included in which arches for composes or produce very ugly spec files with a
ton of arches listed under ExcludeArch. An ExclusiveArch of noarch would
mean that the package gets included on EVERY arch when we compose the
distribution.
There are two camps here, one is that "If your package only WORKS on a
particular arch, it should be BuildArch'd there as to be tagged as such".
The other camp is "If your package is comprised of noarch files (scripts), it
must be marked as such." (and really a third workaround camp that is "You
should use ExcludeArch rather than ExclusiveArch.)
The build software team is on the fence about this, especially as it echos to
packaging guidelines and we'd like to see some discussion out in the
community regarding this issue, and hopefully some policy that we can follow.
The way I see it, if your package is comprised of non-compiled arch
independent content, it MUST be noarch. We can make our build system honor
BuildArch: noarch and ExclusiveArch: i386 x86_64. This would be somewhat
inline with doing BuildArch: noarch, ExcludeArch: foo bar baz baal, because
ExcludeArch would still have 'noarch' in the list. I just don't want to see
either A) having to list out every single possible arch this package may be
built for, or B) screwing over folks like Aurora by only ExcludeArching the
arches our build system would attempt, forcing folks like Aurora to edit spec
files to do their rebuilds.
A side question is, what does plague do in this scenario?
--
Jesse Keating
Release Engineer: Fedora
17 years, 10 months
Single package directory ownership
by Jesse Keating
I'm running into a situation with this rule.
The xorg package set. There is xorg-x11-server-Xorg, and a lot of
xorg-x11-drv-foo packages. The drv packages drop files
in /usr/lib/xorg/modules and /usr/lib/xorg/modules/drivers (lib64 for
obvious places). However, xorg-x11-server-Xorg also puts files there.
Normally we'd say that xorg-x11-server-Xorg must own those directories and
not the drivers. BUT xorg-x11-server-Xorg requires drivers, drivers require
Xorg, insert dep loop here.
The X folks think that when RPM is faced with this, it will make an arbitrary
decision at where to do the transaction, and there could be a case where
xorg-x11-server-Xorg is removed before a drv package, and unless all the drv
packages own the modules and drivers dirs, those directories could get left
behind.
Does this qualify as an exception to the single ownership rule? I've cc'd
Mike and Ajax from the X team as they are not on this list. Please include
them in CCs for the discussion (reply-all on smart clients).
--
Jesse Keating
Release Engineer: Fedora
17 years, 10 months
fc5.90/fc5.91/... disttags and automated rebuilds (was: Mass rebuild of Extras packages for FC6?)
by Axel Thimm
On Sat, Jul 01, 2006 at 12:25:54PM +0200, Thorsten Leemhuis wrote:
> I suppose a lot of people won't like the topic I'll bring up with this
> mail but we IMHO should discuss this nevertheless.
>
> Jesse Keating schrieb:
> > I've been requested to rebuild every Core package for a few reasons.
> >
> > 1) rpm signing w/ sha256sum
> > 2) New toolset feature to speed up dynamic lib linking by 50%~
> > 3) get all packages built through new build system (brew)
>
> Change the last point to
>
> 3) get all packages build with the new and reduced set of packages
> installed in the default mock buildroot
All the above three could be automated for packages using %{?dist}, if
the disttag would propagate in fedora time as well. E.g. the internal
release version of FC6test1 is 5.90, if the disttag was matched to
this, we would have automated rebuilds for each test release and for
the final release as well w/o anyone having to do anything about it
(sparing bugs of course).
If rebuilds are needed more often (because gcc was upgraded in
between) then disttags could look like 5.90.1 to indicate a rebuild
between test1 and test2. Before test1 rawhide had the version 5.89, so
we're covered in that area, too.
If we're going to mass-rebuilt (and therefore touch each specfile),
could we consider using such disttags for rawhide/test releases from
now on? E.g. make %{?dist} become 5.90.1 is the mass rebuild is
before test2, or if the mass rebuild coincides with test2 go 5.91.
It doesn't cover packages not using disttags (so it's perhaps another
incentive for these packagers to use them) and due to everything being
automated doesn't serve as a way to ping absent packagers. But that
was only a side effect of the humanly powered mass-rebuilds, which
will be managed differently anyway in the future.
--
Axel.Thimm at ATrpms.net
17 years, 10 months
New Mono Page for new guidelines
by Toshio Kuratomi
I've reworked the Mono page to reflect the new Guidelines we confirmed
yesterday. If people want to take a look, it's here:
http://fedoraproject.org/wiki/PackagingDrafts/Mono
Changes are color coded: Red removes, green adds, blue is a
justification for people who didn't attend the meeting and will be
removed from the final copy. (I probably should have done this before
the meeting rather than after, sorry.)
If no one objects, I'll replace the current Packaging/Mono page this
weekend.
This is also an example of how the PackagingDrafts area could be used to
work on new or revised Drafts. DavidLutterkort's RubyGems is another:
http://fedoraproject.org/wiki/PackagingDrafts/RubyGems
-Toshio
17 years, 10 months
Disttags for FL (was: Upgrade path consistency among all Fedora Projects)
by Axel Thimm
On Sat, Jul 01, 2006 at 02:58:10AM -0500, David D. Eisenstein wrote:
> Have a quick question for you, Tom. Is there a methodolgy in place
> already for how Core and/or Extras packages are to be versioned in the
> "Release:" part of the packages' .spec files? I am thinking that if
> there is such, then we in Legacy will need to follow that and revise our
> package numbering guidelines
> (current: <http://www.fedoraproject.org/wiki/Legacy/RPMVersioning>)
> to follow it from now on. If no such methodology is used or mandated,
> then does numbering of the "Release:" tag needs to be codified among all
> Fedora projects?
>
> I look forward to your answer, Tom. Thanks! -David
>
> ps: How may I participate in the Packaging group?
>
I'll try to answer on the questions raised to Tom: The (now common to
both core and extras) Fedora Packaging Guidelines
http://www.fedoraproject.org/wiki/Packaging/Guidelines
don't yet explicitely mention the usage of (the optional) disttags
http://www.fedoraproject.org/wiki/DistTag
but they are in common use throughout extras and will hopefully make
their way to core soon.
But note that the disttags used here for rhlX would generate broken
upgrade paths ("rhl" > "fc"). These are very early suggestions and
since extras started with FC3 it never became an actual issue, but if
FL is seeking for following the packaging guidelines including
disttags taking this implementation would be wrong.
If there is interest in FL to introduce and use disttags before RH7.,3
and RH9 are EOL'd, RHL7.3 and RH9 would need to get disttags < fcX.
Examples stated in the past were "RHL7.3" or "fc0.7.3" (upper case is
less than lower case and RHL would be considered like subversions of
FC0). I would vote for the first version (even though it looks like
fortran/shouting) as fc0.7.3 will probably confuse end users.
You can get involved with the packaging group (if you mean the newly
created packaging committee) by subscribing to fedora-packaging and
visiting the IRC meetings on Thursdays 16:00 UTC. Jesse Keating is
also on board so there.
--
Axel.Thimm at ATrpms.net
17 years, 10 months
Re: rpms/haddock/devel haddock.spec,1.2,1.3
by Ralf Corsepius
On Thu, 2006-06-29 at 20:11 -0700, Jens Petersen wrote:
> Author: petersen
>
> Update of /cvs/extras/rpms/haddock/devel
> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv16242
>
> Modified Files:
> haddock.spec
> Log Message:
> - set selinux unconfined_execmem_exec_t context to allow running under
> targeted policy (#195821)
>
>
>
> Index: haddock.spec
> ===================================================================
> RCS file: /cvs/extras/rpms/haddock/devel/haddock.spec,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -r1.2 -r1.3
> --- haddock.spec 29 Jun 2006 12:23:45 -0000 1.2
> +++ haddock.spec 30 Jun 2006 03:11:26 -0000 1.3
> @@ -10,6 +10,8 @@
> BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
>
> BuildRequires: ghc libxslt docbook-style-xsl
> +# need chcon
> +PreReq: coreutils
>
> %description
> Haddock is a tool for automatically generating hyperlinked documentation from
> @@ -53,6 +55,11 @@
> %clean
> rm -rf ${RPM_BUILD_ROOT}
>
> +
> +%post
> +/usr/bin/chcon -t unconfined_execmem_exec_t %{_libexecdir}/haddock.bin >/dev/null 2>&1 || :
I think, we should implement a policy to make
* Requires(pre|post)
mandatory instead of PreReq
* To make file deps on tools being used in %pre|post scripts mandatory.
Ralf
17 years, 10 months
