packaging June 2008

packaging@lists.fedoraproject.org

45 participants
35 discussions

Ownership of /etc/maven/fragments and /usr/share/maven2/poms
by Jason L Tibbitts III 30 Jun '08

30 Jun '08

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<

3 2

Re: [fedora-java] Re: Ownership of /etc/maven/fragments and /usr/share/maven2/poms
by Deepak Bhole 30 Jun '08

30 Jun '08

* 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-----

1 0

[Fwd: [Fedora-packaging] Ownership of /etc/maven/fragments and /usr/share/maven2/poms]
by Nicolas Mailhot 28 Jun '08

28 Jun '08

[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

1 0

Ownership of /etc/maven/fragments and /usr/share/maven2/poms
by Jason L Tibbitts III 28 Jun '08

28 Jun '08

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<

1 0

Packaging of Nagios
by Matthew Jurgens 26 Jun '08

26 Jun '08

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?

2 2

[Fwd: Packaging of Nagios]
by Matthew Jurgens 26 Jun '08

26 Jun '08

I am referring to Nagios v3

1 0

moc, moc-qt4?
by Chris Spencer 26 Jun '08

26 Jun '08

-----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-----

3 8

Requires(hint):
by Jason L Tibbitts III 26 Jun '08

26 Jun '08

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<

12 24

Customizing Fedora Installer
by Amir Franco Joven 25 Jun '08

25 Jun '08

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

2 2

Best practices for packaging logfiles
by Jason L Tibbitts III 22 Jun '08

22 Jun '08

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<

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging June 2008