Re: rawhide report: 20060721 changes
by Rex Dieter
buildsys(a)redhat.com wrote:
> Updated Packages:
...
> alsa-lib-1.0.12-1.rc1
> alsa-utils-1.0.12-1.rc1
Red alert. Packaging/NamingGuidelines have been breached. Raise shields.
(:
-- Rex
17 years, 4 months
Yum Kernel Module Plugin
by Jack Neely
Folks,
I did some work on the fedorakmod.py plugin for Yum a couple weeks ago
before I left for a bit of vacation. I've returned *sigh* and haven't
seen any feedback from it.
The code is in yum-utils CVS and will be in that package the next time
its released. I support kernel module upgrading (where an older module
needs to be removed to avoid file conflicts) and pinning the kernel
until the kernel modules the system uses are available for the new
kernel.
What functionality from the plugin would folks like to see in FC6 so
that we could be closer to having kernel modules in extras?
Jack
--
Jack Neely <jjneely(a)ncsu.edu>
Campus Linux Services Project Lead
Information Technology Division, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89
17 years, 4 months
Re: [Bug 198881] Review Request: perl-POE-Filter-IRCD
by Ralf Corsepius
On Wed, 2006-07-19 at 00:55 -0400, bugzilla(a)redhat.com wrote:
> Please do not reply directly to this email. All additional
> comments should be made in the comments box of this bug report.
>
> Summary: Review Request: perl-POE-Filter-IRCD
>
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198881
>
>
> cweyl(a)alumni.drew.edu changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> Status|ASSIGNED |CLOSED
> Resolution| |NEXTRELEASE
>
>
>
>
> ------- Additional Comments From cweyl(a)alumni.drew.edu 2006-07-19 00:46 EST -------
> Ok, I think the rhetoric here is getting a touch out of hand, and making a very
> large issue out of a not-so-large one.
>
> Perl modules are fairly "special", in that basically the same specfile can
> handle all of them (with package specific description, etc, being adapted, of
> course). They're also special in that there's a LOT of them.
>
> For those two reasons, I try to hew as close to the specfile template as
> possible. --> The closer to the template a perl module spec is the more readily
> apparent errors are, especially when there's a _lot_ of them. <--
I beg to differ. IMO, you are slavishly copying without thinking what you are doing.
> It's easy to scan a perl spec and almost instinctively know when something is
> missing, when as little deviation as necessary is made from it.
The only party which deviates is Tibbs/Weyl.
If Jason had directed you to drop OPTIMIZE/find *.bs from the very
beginning, as probably all other perl-package reviewers in the past have
done, this would have not escalated.
IIRC, JPO, Steve P., Jesse Keating, Paul H., Warren T. and me have all
done so in the past.
> Ralf, I do not do this "mindlessly", "without thinking", or "sloppily". I do
> check to ensure the extra lines (w.r.t. OPTIMIZE) doesn't adversely impact the
> building of the package. I'm not resistant to learning, and in fact find myself
> learning daily and seeking input. To date I haven't been provided with any
> reason why, in my judgement, it would be advantagous to abandon this practice.
Well, that's not the impression you make on me. I regret having to say
this, but I sense you as a person who seems to need "regulations" for
each any every bit he writes and who doesn't have understood the meaning
of "templates"
Templates are supposed to be filled with life by humans, not to be
slavishly copied.
> If you want, bring this issue before the packaging committee.
In Fedora it has always been common agreement to keep specs minimal and
not to clutter/pollute them with potentially harmful junk.
Ralf
17 years, 4 months
Re: atrpms kernel modules
by Axel Thimm
On Tue, Jul 18, 2006 at 01:59:34PM +0200, Eric Tanguy wrote:
> > kernels=`rpm -qf /boot/vmlinuz-* | grep -v "^file .* is not owned by any package"`
> > uname_rs=`rpm -ql $kernels | grep ^/boot/vmlinuz- | sed -e's,^/boot/vmlinuz-\(.*\)$,\1,'`
> > for kmdl in `rpm -qa \*kmdl\* | sed -e's,-kmdl-.*,-kmdl,' | sort -u`;
> > do
> > for uname_r in $uname_rs; do
> > package=${kmdl}-$uname_r
> > rpm -q $package > /dev/null 2>&1 || echo $package
> > done
> > done | xargs -r smart install -y
>
> Ok this script seems to use smart. is it working with yum ?
Yes, I think "smart install -y" -> "yum -y install" is the only change
needed. And for apt it would be "apt-get -y install".
> How is this problem handled by livna because it works fine using
> this repo : the kernel modules are installed and not updated
> It's known that there are issues with this scheme, or any scheme
> that will merge module and kernel versions.
rpm for one can't cope with it. Suppose you have two active kernels
(say 2.6.16 and 2.6.17 or xen0 and non-xen0 etc.) and already have
foo-kmdl for both in version 1. Now foo-kmdl in version 2 is
released. Both rpm -i (coinstall, no replacement of of foo-kmdl for
the same kernel) and rpm -U (remove all foo-kmdl but the highest one,
e.g. at least one kernel stay w/o any kmdl) won't work.
yum/smart/apt can be tought to be more clever than rpm and try to do
the proper thing, which they will only be able to do if the merged
versions are distangled again, e.g. hidden in Provides: and the like.
So in order for a merged-version scheme to work there is special
handling neccessary (and for atrpms' system, too, but read on). I
prefer to have rpm itself already do something sensible and since it
can only upgrade one versioning system (e.g. either the kernel's or
the module's) it's preferable to allow it to upgrade the module within
the same kernel and not touch the cross-kernel boundaries. "No harm
done" like accidentially removing kmdls for other kernels or
coinstalling several kmdls for the same kernel. You "only" need to
reinstall the missing kmdl upon each kernel upgrade.
It's far easier to get this into the brains of yum/smart/apt
(e.g. translate the 9 lines of bash above into plugings/hooks for
these depsolvers) or simply use the 9liner above than have a scheme
which is broken at the level of rpm.
Incidentially one on my personal targets is to get thie discussed in
the fedora packaging group and review the currently scheme. Of course,
I'm proposing adoption of ATrpms' kmdl scheme :)
http://www.fedoraproject.org/wiki/Packaging/GuidelinesTodo
> when i install a new kernel and are removed when the kernel is
> removed.
How the dependencies to the kernel are installed (which is responsible
for having an automatic removal on kernel removal) is a different
story, which the version merging does not break. The issue is with the
system (system=rpm and(or any higher depsolver tool,
e.g. yum/smart/apt) being able to distinguish different foo-kmdls as
_upgrades_ vs _coinstalls_.
--
Axel.Thimm at ATrpms.net
--
fedora-list mailing list
fedora-list(a)redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
17 years, 4 months
Java Naming Page
by Toshio Kuratomi
I've added a Java Naming page to PackagingDrafts::
http://www.fedoraproject.org/wiki/PackagingDrafts/JavaPackageNaming
Feel free to review it and see if I've missed anything, misstated the
effects of naming according to a certain proposal, etc.
I think before anything can be decided we have to identify which of the
goals on that page (and any others that might be out there) are real
goals and which are not. As lutter said, if it really is a goal to
allow interleaved updates between Fedora and jpackage repositories, then
the releases have to start with the jpackage version.
I have more ideas to place under the discussion sections but I'm going
home to deal with termites and a clogged sewer line so I might not get
to it for a while.
-Toshio
17 years, 4 months
installation of info files
by Till Maas
Hiyas,
the guidelines do not mention how to install .info files the right way. At the
moment there seem to be several scriptlets used to install them in %post
and %preun. I want to suggest to define a rpm-macro that handles info files
in the right way which also would reduce redundant lines of code in
spec-files. Something like "%info" in the files section would be most useful
in my oppionion, like it already exists for documentation (%doc).
What are your oppionions about this?
Regards,
Till
17 years, 4 months
PHP packaging policy notes
by Joe Orton
cc'ing Tim since we had lots of discussion about much of this stuff
already and I'm not sure if he's on fedora-packaging (I didn't even know
that list existed...)
I was planning to add a "php-abi = <PHP_API_VERSION>" definition for C
ABI versioning rather than php(ABI).
Versioning language features in PHP a la MODULE_COMPAT_* is just not
going to be feasible; the language is not well-defined enough nor stable
enough for us to try and enforce versioning; plus stuff like
"zend.ze1_compatibility_mode" means the exposed language is dependent on
config options anyway.
I don't see why it's necessary for a PEAR package to require
php-pear(PEAR); that is somewhat equivalent to an RPM having "Requires:
rpm"; it should be sufficient and correct for PEAR packages to simply
"Requires: php-pear" AFAICS.
Why should a PEAR package for foo provide php-foo? Not sure that's a
good idea.
On "Other Packages": an application written in PHP or such like should
not have a php- prefix at all. A Smarty package should be called
"smarty" (following the "upper-case is evil" rule of packaging).
joe
17 years, 4 months
Packaging Committee Information
by Toshio Kuratomi
I've started a page for packaging committee with the date and time of
the meetings and other information. If you want to find out about the
packaging committee go ahead and read it. If you're on the Packaging
Committee and want to hack it, go ahead. If you don't have permission
to edit the page but want something added or modified, send mail to
fedora-packaging or hop onto #fedora-packaging on IRC.
http://www.fedoraproject.org/wiki/Packaging/Committee
-Toshio
17 years, 4 months
