Updates to Eclipse Plugin packaging guidelines
by Andrew Overholt
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
15 years
Moonlight support within MonoDevelop
by Paul F. Johnson
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!
15 years, 1 month
Re: Fontconfig rules installation guidelines change proposal
by Nicolas Mailhot
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
15 years, 1 month
Re: Fontconfig rules installation guidelines change proposal
by Nicolas Mailhot
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
15 years, 1 month
libgdiplus-devel subpackage
by Paul F. Johnson
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!
15 years, 1 month
