Wiki is inconsistent on Mono file locations
by Mary Ellen Foster
Disclaimer: I'm not a Mono programmer; I'm just trying to package
something that includes some Mono pieces.
I was looking at the Wiki about packaging for Mono
(http://fedoraproject.org/wiki/Packaging/Mono), and it seems to
contradict itself. Under "File locations", it says
Mono packages should install assemblies to %{_libdir}
rather than /usr/lib or %{_datadir}
Then, right below, it gives sample gacutil lines that install into
%{_prefix}/lib, with a note that it might later change to %{_libdir}
and a link to a bug with a lot of discussion, but no clear indication
of whether the proposal was accepted or not.
So, should my stuff go into %{_libdir} or %{_prefix}/lib?
Thanks very much!
MEF
--
Mary Ellen Foster
http://homepages.inf.ed.ac.uk/mef/
16 years, 8 months
commands under privileged users' path
by Mamoru Tasaka
Well, currently I am reviewing several reviewing requests
and I asked a submitter to change user/group registration
scriptlets according to
http://fedoraproject.org/wiki/Packaging/UsersAndGroups
and he/she changed as such.
Then I noticed :
%pre servers
# Following the Wiki instructions ...
getent group iceuser > /dev/null || groupadd -r iceuser
<snip>
Here "groupadd" (which is in Fedora under /usr/sbin)
is used by only basename, not by full path. IMO this will cause
a problem when "yum update" or "rpm -ivh" is done by normal
users using "su -c" or "sudo" because normal users usually
don't have /usr/sbin in their path.
So I think that the following should be added to the wiki
that commands which are under privileged users' path and
not under normal users' path must be written with full path.
Do you have any suggestions?
Regards,
Mamoru
16 years, 8 months
Re: [Fedora-packaging] review guidelines vs packaging guidelines
by Nicolas Mailhot
Le Jeu 23 août 2007 12:58, Patrice Dumas a écrit :
> Ok, I didn't understood it that way. But it isn't true, the guidelines
> are setup such that having no ownership of a directory is impossible.
I'm not so sure. The lax guidelines are more ambiguous, at no time do
they clearly say "every directory must be owned" (with single or
multiple owners). They say "the rule of thumb is everything must be
owned but there are exceptions". And then proceed with some examples
where every directory is accounted for without explicitely stating
this is a hard rule. I don't think the OP would have been so happy
with the lax version if he had understood them to enforce this rule.
IMHO since the documented "exceptions" are clearly targetted at perl
modules, it would be better to create a perl-filesystem package and
forget about all the complex A/B convolutions in the guidelines. But
that's for the perl SIG to discuss.
--
Nicolas Mailhot
16 years, 8 months
Re: [Fedora-packaging] review guidelines vs packaging guidelines
by Nicolas Mailhot
Le Jeu 23 août 2007 11:52, Patrice Dumas a écrit :
> It is not always worth creating a filesystem package for these cases.
> Simply having more than one package own the directory is simpler, and
> although not perfect, acceptable.
When two packages share a directory sure it's not worth creating a
separate package just for this directory. What I was suggesting was
more like the games SIG collecting all the stray directories in a
filesystem-games package, same for the perl SIG, etc Certainly there
is a level at which you can create useful filesystem packages without
falling in the whole-repository or single-directory package traps.
That being said multiple ownership is compliant with the strict
guidelines version, what I object to is no ownership as suggested by
the lax variant.
Regards,
--
Nicolas Mailhot
16 years, 8 months
review guidelines vs packaging guidelines
by Matthias Clasen
The review guidelines have this:
- MUST: A package must own all directories that it creates. If it does
not create a directory that it uses, then it should require a package
which does create that directory. The exception to this are directories
listed explicitly in the Filesystem Hierarchy Standard
(http://www.pathname.com/fhs/pub/fhs-2.3.html), as it is safe to assume
that those directories exist.
The packaging guidelines say:
The rule of thumb is that your package should own all of the directories
it creates except those owned by packages which your package depends on.
However, there are exceptions to this. If the directory hierarchy your
package is located in may change due to updates of packages you depend
on, then you need to take care to own those pieces of the hierarchy.
[...]
Another exception for directory ownership in packages is when there is
no clear dependency hierarchy.
I think the shortened version in the review guidelines is misleading and
causes us to err on the side of adding unwanted dependencies just for
directory ownership reasons. Can we have it changed to mention the
furhter exceptions that are discussed in the packaging guidelines ?
16 years, 8 months
Are circular dependencies ok?
by Stepan Kasal
Hello,
in perl, circular dependencies are heavily used.
First, "perl" and "perl-libs" require each other; this is a usual
solution of the multilib problem, rpm{,-libs} and python{,-libs}
are doing the same. Let's put this aside.
Second, package "perl-devel" requires packages:
perl-CPAN
perl-ExtUtils-Embed
perl-ExtUtils-MakeMaker
perl-Test-Harness
perl-Test-Simple
all these packages require perl-devel, most of them by a direct
requirement, only perl-CPAN by requiring perl-ExtUtils-Embed.
I believe this is correct:
- the modules have to have separate rpm, to match the real situation:
they use a separate versioning scheme, for example.
- perl-devel has to require them; these modules are required by
scripts packed in perl-devel
But this seems to bring problems, see the comments in
https://admin.fedoraproject.org/updates/testing/F7/perl-5.8.8-22.fc7
Is this just a bug in yum, or is there a problem on my side?
Thanks,
Stepan Kasal
16 years, 8 months
Missing the meeting today
by Toshio Kuratomi
Sorry for the last minuteness of this,
My sister's stuck at the airport so I'll be missing the meeting.
-Toshio
16 years, 8 months
Missing today's meeting
by Ralf Corsepius
Hi,
due to sudden unplanned commitments, I'll not be able to attend today's
FPC meeting.
Ralf
16 years, 8 months
