Ownership of /etc/maven/fragments and /usr/share/maven2/poms
by Jason L Tibbitts III
Sorry for the resend; this should have the correct address for the
java list.
I hope I'm CC'ing this sufficiently; I do not know if any
representatives form the Java group are members of fedora-packaging.
I was reviewing my first maven-using package and ran into an issue
with the Java packaging guidelines. Namely that they specify that
every maven-using package should own /etc/maven/fragments and
/usr/share/maven2/poms, which contradicts our usual policy on
directory ownership by multiple packages.
I don't really understand why the packages would need to own those
directories; jpackage-utils already serves as a kind of filesystem
package for java, it already owns /etc/maven and several
java-related directories in /usr/share, and all of the packages which
would own files in the two directories at issue already depend on it.
So I think jpackage-utils should just own /etc/maven/fragments and
/usr/share/maven2/poms and we can tweak the guidelines to not specify
that the individual packages own these directory.
Another possibility would be to shift this off to a java-filesystem
package analogous to our other *-filesystem packages which could own
these and various other java directories.
This would fix ownership issues for 22 packages currently.
Another separate bug related issue is the fact that the contents of
/etc/maven/fragments do not seem to be configuration files, and so
probably should not live under /etc. I do not have sufficient Java
knowledge to propose a solution, however.
- J<
15 years, 3 months
Re: [fedora-java] Re: Ownership of /etc/maven/fragments and /usr/share/maven2/poms
by Deepak Bhole
* David Walluck <david(a)zarb.org> [2008-06-30 13:04]:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Deepak Bhole wrote:
> | I think moving them to jpackage-utils would be sufficient, as it owns a
> | multitude of other java related directories right now. I have put this
>
> I agree. This is consistent since %{_sysconfdir}/maven is already owned
> by jpackage-utils.
>
> | Correct, technically they are not configuration related files. I'd be
> happy to
>
> Config files are specified to always have %config(noreplace) (in my
> rpmlint anyway). So, unless they are user-editable files that can be
> kept between upgrades, then they should be moved. I think that since
> these files aren't meant to be editable and in fact must be kept in sync
> with package upgrades they are not proper config files and should be moved.
>
> | move them, but I am not sure what the best place for them is either :/ ..
> | suggestions are welcome. The files serve as configuration in the sense
> | that they provide maven with a "mapping" between where maven expects
> | jars to be, and where they actually are on the system.
>
> The obvious choice seems to be %{_datadir}/maven2/fragments and most
> other files appear to be in %{_datadir}/maven2.
>
Yep I am fine with this. I will make the change for the next version. A
change of this sort will require rebuild of all maven2 dependent
packages.
> The important thing besides single ownership by jpackage-utils is to
> move the maven macros into jpackage.macros so that you don't have to
> change every spec just to change the location of the files.
>
The fragment dir location is already a macros, and all maven related macros
are in jpackage-utils already.
Cheers,
Deepak
> - --
> Sincerely,
>
> David Walluck
> <david(a)zarb.org>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkhpEhYACgkQItObMyg2XCVcZwCgsmj7Go0jDO5YjRb2s/5iKsxp
> HYUAn21+dloZoJ3A0boYwr3nqfaGuWy1
> =M/Pp
> -----END PGP SIGNATURE-----
15 years, 3 months
[Fwd: [Fedora-packaging] Ownership of /etc/maven/fragments and /usr/share/maven2/poms]
by Nicolas Mailhot
[adding jpp-discuss to the list]
-------- Message transféré --------
De: Jason L Tibbitts III <tibbs at math.uh.edu>
Sujet: [Fedora-packaging] Ownership of /etc/maven/fragments
and /usr/share/maven2/poms
Date: 28 Jun 2008 17:22:51 -0500
Sorry for the resend; this should have the correct address for the
java list.
I hope I'm CC'ing this sufficiently; I do not know if any
representatives form the Java group are members of fedora-packaging.
I was reviewing my first maven-using package and ran into an issue
with the Java packaging guidelines. Namely that they specify that
every maven-using package should own /etc/maven/fragments and
/usr/share/maven2/poms, which contradicts our usual policy on
directory ownership by multiple packages.
I don't really understand why the packages would need to own those
directories; jpackage-utils already serves as a kind of filesystem
package for java, it already owns /etc/maven and several
java-related directories in /usr/share, and all of the packages which
would own files in the two directories at issue already depend on it.
So I think jpackage-utils should just own /etc/maven/fragments and
/usr/share/maven2/poms and we can tweak the guidelines to not specify
that the individual packages own these directory.
Another possibility would be to shift this off to a java-filesystem
package analogous to our other *-filesystem packages which could own
these and various other java directories.
This would fix ownership issues for 22 packages currently.
Another separate bug related issue is the fact that the contents of
/etc/maven/fragments do not seem to be configuration files, and so
probably should not live under /etc. I do not have sufficient Java
knowledge to propose a solution, however.
- J<
--
Fedora-packaging mailing list
Fedora-packaging(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
--
Nicolas Mailhot
15 years, 3 months
Ownership of /etc/maven/fragments and /usr/share/maven2/poms
by Jason L Tibbitts III
I hope I'm CC'ing this sufficiently; I do not know if any
representatives form the Java group are members of fedora-packaging.
I was reviewing my first maven-using package and ran into an issue
with the Java packaging guidelines. Namely that they specify that
every maven-using package should own /etc/maven/fragments and
/usr/share/maven2/poms, which contradicts our usual policy on
directory ownership by multiple packages.
I don't really understand why the packages would need to own those
directories; jpackage-utils already serves as a kind of filesystem
package for java, it already owns /etc/maven and several
java-related directories in /usr/share, and all of the packages which
would own files in the two directories at issue already depend on it.
So I think jpackage-utils should just own /etc/maven/fragments and
/usr/share/maven2/poms and we can tweak the guidelines to not specify
that the individual packages own these directory.
Another possibility would be to shift this off to a java-filesystem
package analogous to our other *-filesystem packages which could own
these and various other java directories.
This would fix ownership issues for 22 packages currently.
Another separate bug related issue is the fact that the contents of
/etc/maven/fragments do not seem to be configuration files, and so
probably should not live under /etc. I do not have sufficient Java
knowledge to propose a solution, however.
- J<
15 years, 3 months
Packaging of Nagios
by Matthew Jurgens
I am waiting for the release of the fedora Nagios package and was
wondering if I could get involved to help speed up the process?
15 years, 3 months
moc, moc-qt4?
by Chris Spencer
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello all,
I am developing a program and have begun testing it on other
distributions, however I am having some trouble getting it to compile on
Fedora.
The configure script checks for the program 'moc' and fails if it
doesn't find it. I have installed the qt-devel package, but for some
reason it installs moc as moc-qt4, no symlink or anything. Can anyone
explain to me why this is, and possibly suggest a suitable workaround?
Cheers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhji64ACgkQ6iqRtkAADZjcJwCdE9SX7+rtJ6yBDYyMZddZ3pra
KVMAoPatrn0RO+ohfDAFBgMBMDLR1zYA
=ZF06
-----END PGP SIGNATURE-----
15 years, 3 months
Requires(hint):
by Jason L Tibbitts III
I've seen packages using Requires(hint): and testing shows that
currently this is handled no differently from a regular Requires:.
I happen to think Requires(hint): is a horrible syntax, because
cognation with Requires(pre, post, preun, etc.): implies that some
%hint scriptlet will be run at some point, but that's neither here nor
there and I suspect that any upstream brain-damage is already a fait
accompli.
However, there's still the question of what to do with Requires(hint):
in Fedora packages. Either we get rid of it or we need to document
what it does and what it might do in the future.
Strawman proposal: ban use of Requires(hint) in Fedora packages.
Comments? Votes from FPC folks?
- J<
15 years, 3 months
Customizing Fedora Installer
by Amir Franco Joven
Hi,
I'm trying to customize the Fedora installer for my orgs use.
The idea is we have apps that we want to include in the fedora cd/dvd
installer,
we only need it for our own, not for the whole fedora distribution.
What I've tried so far is pungi, and yes, I was able to produce an updated
installer.
the only problem that i have now is i dont know which files to modify to add
our app in the package selection
can someone point me to a document that i should read to carry out our plan?
or is this really possible?
Thank you very much in advance.
Best regards,
Amir
15 years, 3 months
Best practices for packaging logfiles
by Jason L Tibbitts III
I noticed a package in the review queue doing this to manage its
logfile:
%post
/sbin/chkconfig --add %{name}
touch %{_localstatedir}/log/%{name}
chown sip:sip %{_localstatedir}/log/%{name}
%files
[...]
%ghost %attr(0644,sip,sip) %{_localstatedir}/log/%{name}
(the sip user/group are created in %pre).
I was unsure of the difference between this and simply owning the file
in %files; the ownership comes out right, but behavior might differ on
upgrades and there's the issue of rpm -V. Does %ghost imply something
like %verify(not md5 size mtime)?
That's the best current practice for doing this?
- J<
15 years, 3 months