packaging October 2008

packaging@lists.fedoraproject.org

42 participants
25 discussions

Updates to Eclipse Plugin packaging guidelines
by Andrew Overholt 08 Dec '08

08 Dec '08

Hi, I have a few updates to the Eclipse Plugin packaging guidelines. They include some clarifications, typos, and updates for Eclipse 3.4.x. The only bit of real substance is modifying the template to note how we're using the dropins mechanism for plugin installation in 3.4.x and above. I've attached a diff 'cause I don't think I can commit it. Can someone else? Thanks, Andrew

5 6

rubygem with extension written in C
by Mamoru Tasaka 19 Nov '08

19 Nov '08

Hello, all: During reviews (and also on my package) I met with some troubles when packaging Ruby Gems containing extension libraries written in C. Would you look at my proposition written in the following URL? https://fedoraproject.org/wiki/User:Mtasaka/PackagingDrafts/RubyGem_with_C_… Any comments will be appreciated. Thank you in advance. Note: I will leave from my computer soon and I will read and reply to comments once I get back from a rest. Regards, Mamoru

3 9

README.Dist is preferrable to README.Fedora
by Patrice Dumas 26 Oct '08

26 Oct '08

Hello, In http://fedoraproject.org/wiki/Packaging/Guidelines#Summary_and_description I suggest changing README.Fedora to README.Dist, see for an argumentation: http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Avoiding_… -- Pat

11 29

BR exception could be simplified
by Patrice Dumas 25 Oct '08

25 Oct '08

Hello, I think that at http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2 the sentence 'The derived list of all deps pulled in by this list is on Packaging/FullExceptionList . ' should be removed, and the Packaging/FullExceptionList page should also be removed. -- Pat

1 0

package without .elc files and emacs guidelines
by Patrice Dumas 24 Oct '08

24 Oct '08

Hello, In the librep there are some .el files, and Michal Jaegermann explained in https://bugzilla.redhat.com/show_bug.cgi?id=431250#c23 that the .elc files are not needed (and sometimes harmful). This is not very consistent with the Emacs guidelines. Maybe the guidelines could be amended for this case? -- Pat

3 3

Moonlight support within MonoDevelop
by Paul F. Johnson 21 Oct '08

21 Oct '08

Hi, I know that moonlight is a no-go area due to Novell's insanity and love up with the Borg, but is support for moonlight from within MonoDevelop also a no-go area? I've asked on the Mono-packaging list if there is a way to disable moonlight support within MD, but I doubt there will be an easy solution. Advice required on this. I don't want to have to start hacking things around if support doesn't violate the rules. TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen!

2 1

PackagingDrafts/AutoConf
by Braden McDaniel 19 Oct '08

19 Oct '08

I would like to make some progress on this: <http://fedoraproject.org/wiki/PackagingDrafts/AutoConf> The goal, I think, is incorporation of something like this into Fedora's Packaging Guidelines. I'm told this is the place to come. -- Braden McDaniel e-mail: <braden(a)endoframe.com> <http://endoframe.com> Jabber: <braden(a)jabber.org>

7 16

Re: Fontconfig rules installation guidelines change proposal
by Nicolas Mailhot 16 Oct '08

16 Oct '08

Le Mer 15 octobre 2008 22:39, Behdad Esfahbod a écrit : > > Nicolas Mailhot wrote: >> Le mercredi 15 octobre 2008 à 15:10 -0400, Behdad Esfahbod a écrit : >>> The idea of having separate conf.avail and conf.d is that sysadmins >>> can >>> symlink/unlink entries into conf.d to enable/disable configuration >>> for their >>> system. This would only work if upgrading fontconfig/fonts rpms >>> does not >>> reinstate the unlinked symlink. However, last time I checked this >>> was not >>> working correctly. Can you check this first? >> >> I didn't write it in the wiki, but as far as I understand rpm it is >> not >> possible to tell it "if this file/symlink does not exist do not >> install >> it". So this bit of conf.avail/conf.d design will never work on rpm >> systems. And even if it worked, what you'd actually need would be >> "if >> this file does not exist and was installed by a previous rpm" to >> handle >> initial deployment. Which starts to be real hairy. > > Well, it is: don't include the symlink in the RPM but create it in > %post, and > only if no previous versions of the package were installed ($1 = 0 > IIRC). Yurk. How safe is it WRT package renames? Because we've been renaming font packages a lot in the past (and I plan another mass rename for F11, hopefully the last one but I wouldn't bet anything I care about on it). Really this is being too clever for your own good IMHO. >> However (someone please check this) it's probably possible to >> disable an >> entry permanently by creating a symlink with the same name pointing >> somewhere else > > This can be ok. If it works, we can document it. >> Also (and this bit is traced on the wiki) as I understand the >> FHS /etc/.../conf.avail is a complete no-go and should be moved >> to /usr/share/something if we want to be clean. And that >> before /etc/.../conf.avail is duplicated in many packages. > > Really? Where does it talk about those kind of stuff? In conf.avail files are not really user-editable config files (in fact you don't use config(noreplace) so any package update will stomp on user modifications). They're more static configuration blocks users can not change but only activate/desactivate in conf.d via symlinks, and as such they match the "read-only architecture independent data files" definition of /usr/share. That rpmlint complains of %config files without noreplace in /etc is a pretty strong hint those files are misplaced. In fact one can wonder what's good is there %config-ing them at all. IIRC there was a pretty long thread on the subject in fedora-devel in the last months, but I don't have the time to pull it from archives. -- Nicolas Mailhot

1 0

Re: Fontconfig rules installation guidelines change proposal
by Nicolas Mailhot 15 Oct '08

15 Oct '08

Le mercredi 15 octobre 2008 à 15:10 -0400, Behdad Esfahbod a écrit : conf.avail and conf.dyyyyyyyyyyyyyyy > Hi Nicolas, Hi Behdad, Thank you for reviewing it, > I like the direction of it. > > The idea of having separate conf.avail and conf.d is that sysadmins can > symlink/unlink entries into conf.d to enable/disable configuration for their > system. This would only work if upgrading fontconfig/fonts rpms does not > reinstate the unlinked symlink. However, last time I checked this was not > working correctly. Can you check this first? I didn't write it in the wiki, but as far as I understand rpm it is not possible to tell it "if this file/symlink does not exist do not install it". So this bit of conf.avail/conf.d design will never work on rpm systems. And even if it worked, what you'd actually need would be "if this file does not exist and was installed by a previous rpm" to handle initial deployment. Which starts to be real hairy. (more generally treating absence of an item as disabling this item is a broken computer pattern IMHO.) However (someone please check this) it's probably possible to disable an entry permanently by creating a symlink with the same name pointing somewhere else (how does fontconfig reacts to /dev/null symlinks or symlinks pointing to empty files)? So having a repository of pre-deployed config snippets is fine with me. Also (and this bit is traced on the wiki) as I understand the FHS /etc/.../conf.avail is a complete no-go and should be moved to /usr/share/something if we want to be clean. And that before /etc/.../conf.avail is duplicated in many packages. -- Nicolas Mailhot

1 0

libgdiplus-devel subpackage
by Paul F. Johnson 14 Oct '08

14 Oct '08

Hi, Currently libgdiplus is broken into devel and the main package as per the packaging rules. However, the .so.0 files in the main package symlink to the -devel, so without the -devel subpackage, libgdiplus has problems. In mono, this is fixed (kind of) by having mono-winforms requiring libgdiplus-devel (which pulls in libgdiplus if it's not already installed). Not the best solution, but one which works. Obviously, this can't be used for libgdiplus. Given the nature of libgdiplus can an exception be made to this package so the .so file is bundled with the main package as well as the .pc file? I know it breaks the packaging regs, but I can't think of another way around it. TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen!

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging October 2008