Le Mer 10 juin 2009 15:29, Panu Matilainen a écrit :
>
> On Wed, 10 Jun 2009, Nicolas Mailhot wrote:
> And this is why the actual script to do whatever magic it
> needs to do, when it needs to, would be in a distros fontconfig
> package, not rpm.
This is totally orthogonal to invoking this scrip
On Wed, 10 Jun 2009, Nicolas Mailhot wrote:
Le Mer 10 juin 2009 13:21, Panu Matilainen a écrit :
File triggers are certainly not the holy grail of packaging, they're
only
applicaple to a pretty limited set of situations, from the top of my
head:
1) Caches updaters which you only want to run
Le Mer 10 juin 2009 13:21, Panu Matilainen a écrit :
>
> File triggers are certainly not the holy grail of packaging, they're
> only
> applicaple to a pretty limited set of situations, from the top of my
> head:
>
> 1) Caches updaters which you only want to run once per transaction:
> - ldconfig
On Wed, 10 Jun 2009, Nicolas Mailhot wrote:
Le Mer 10 juin 2009 10:59, Florian Festi a écrit :
Nicolas Mailhot wrote:
1. something auto-triggered transparently (didn't we learn anything
from
existing package triggers?).
I think you make the wrong comparison here (although I admit that the
Le Mer 10 juin 2009 10:59, Florian Festi a écrit :
>
> Nicolas Mailhot wrote:
>> 1. something auto-triggered transparently (didn't we learn anything
>> from
>> existing package triggers?).
>
> I think you make the wrong comparison here (although I admit that the
> matching names make it tempting
Nicolas Mailhot wrote:
Le lundi 08 juin 2009 à 20:13 +0200, Florian Festi a écrit :
This approach has several shortcomings (forgetting the technical
details). It requires a lot of data be shipped with each package.
I think you misunderstood me. I'd want the definition for %font of %
icon-dir
Colin Walters wrote:
> On Tue, Jun 9, 2009 at 11:22 AM, Kevin Kofler
> wrote:
>> The makefile could also be autogenerated from an unknown build tool
>
> Makefiles generated by e.g. automake have easily detectable patterns.
> Try "head Makefile".
I wrote "UNKNOWN build tool". Of course you can de
On Tue, Jun 9, 2009 at 11:22 AM, Kevin Kofler wrote:
> Colin Walters wrote:
>> If such a thing were to be implemented it'd probably be good to use it
>> to clean out the wishlist in general, like handling %clean and even
>> %build automatically (e.g. if we see a configure script, just assume
>> to
Colin Walters wrote:
> If such a thing were to be implemented it'd probably be good to use it
> to clean out the wishlist in general, like handling %clean and even
> %build automatically (e.g. if we see a configure script, just assume
> to call "%{configure}", see a Makefile, just assume to call "m
Le lundi 08 juin 2009 à 20:13 +0200, Florian Festi a écrit :
>
> This approach has several shortcomings (forgetting the technical
> details). It requires a lot of data be shipped with each package.
I think you misunderstood me. I'd want the definition for %font of %
icon-dir to be factored-out
On Sat, Jun 6, 2009 at 6:01 AM, Panu Matilainen wrote:
>
> The hardest part is getting the design right the first time, there's no
> changing an "api" that is exposed to packages.
It's definitely better to get things "right" the first time, but one
thing missing from the system now is any kind of
Nicolas Mailhot wrote:
Le samedi 06 juin 2009 à 13:01 +0300, Panu Matilainen a écrit :
Yes, having each and every spec carry the %{!?foo:¤%&¤%} macro goo makes
no sense at all.
That is pretty much what we did for fonts in F11. However many packagers
just ignored the change and didn't
On Mon, 2009-06-08 at 13:31 +0200, Nicolas Mailhot wrote:
> Le dimanche 07 juin 2009 à 12:31 +0300, Panu Matilainen a écrit :
>
> > Btw your initial suggestion of collecting the common stuff into macros
> > and converting packages to use them would be useful on several ways:
> > a) Finding out th
On Mon, 2009-06-08 at 15:45 +0200, Nicolas Mailhot wrote:
> Le lundi 08 juin 2009 à 09:34 -0400, Matthias Clasen a écrit :
> > On Mon, 2009-06-08 at 13:25 +0200, Nicolas Mailhot wrote:
> >
> > > I personally think it would be a huge mistake to have stuff happen
> > > automatically based on filenam
Le lundi 08 juin 2009 à 09:34 -0400, Matthias Clasen a écrit :
> On Mon, 2009-06-08 at 13:25 +0200, Nicolas Mailhot wrote:
>
> > I personally think it would be a huge mistake to have stuff happen
> > automatically based on filename/location heuristics. Naming collisions
> > happen all the time (fo
On Mon, 2009-06-08 at 13:25 +0200, Nicolas Mailhot wrote:
> I personally think it would be a huge mistake to have stuff happen
> automatically based on filename/location heuristics. Naming collisions
> happen all the time (for example GNOME recently decided that a third of
> our fonts were "ODF te
Le dimanche 07 juin 2009 à 12:31 +0300, Panu Matilainen a écrit :
> Btw your initial suggestion of collecting the common stuff into macros
> and converting packages to use them would be useful on several ways:
> a) Finding out the things that *are* common among lots of packages. While
> numer
Le samedi 06 juin 2009 à 13:01 +0300, Panu Matilainen a écrit :
> Yes, having each and every spec carry the %{!?foo:¤%&¤%} macro goo makes
> no sense at all.
That is pretty much what we did for fonts in F11. However many packagers
just ignored the change and didn't fix their packages.
> >>> For
On Sat, 6 Jun 2009, Adam Williamson wrote:
On Sat, 2009-06-06 at 15:47 +0300, Panu Matilainen wrote:
On Sat, 6 Jun 2009, Panu Matilainen wrote:
I'm glad to see I'm not the only one who replies to himself :)
Heh :)
Also for ultimate power the file triggers need to be in headers so that all
On Sat, 2009-06-06 at 11:49 -0500, Bruno Wolff III wrote:
> On Fri, Jun 05, 2009 at 10:31:23 -0700,
> Adam Williamson wrote:
> >
> > https://fedoraproject.org/wiki/Packaging/ScriptletSnippets
> >
> > it seems to me that this is a bit of a silly approach - it encourages
> > cut and paste errors
On Sat, Jun 6, 2009 at 6:44 PM, Kevin Kofler wrote:
> yersinia wrote:
> > In @rpm5.org, yes.
>
> rpm5.org is not the upstream for Fedora's RPM.
>
Sure, but it is only for info. Anyway it is only for MANDRIVA vendor in
configure. Exists so many rpm fork in place in the world.
Regards
--
fedora-
On Fri, Jun 05, 2009 at 10:31:23 -0700,
Adam Williamson wrote:
>
> https://fedoraproject.org/wiki/Packaging/ScriptletSnippets
>
> it seems to me that this is a bit of a silly approach - it encourages
> cut and paste errors (or people cutting and pasting non-canonical blocks
> from other people
yersinia wrote:
> In @rpm5.org, yes.
rpm5.org is not the upstream for Fedora's RPM.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Sat, 2009-06-06 at 15:47 +0300, Panu Matilainen wrote:
> On Sat, 6 Jun 2009, Panu Matilainen wrote:
I'm glad to see I'm not the only one who replies to himself :)
> >
> > Also for ultimate power the file triggers need to be in headers so that all
> > triggers are ready for action before the t
On Fri, Jun 5, 2009 at 8:05 PM, Adam Williamson wrote:
> On Fri, 2009-06-05 at 13:50 -0400, Ray Strode wrote:
>
> > > It seems to me it'd make sense to convert all these kinds of snippets
> > > into macros. Am I right, or is there a reason against doing this?
> > It would be awesome to get rid of
On Sat, 6 Jun 2009, Panu Matilainen wrote:
Also for ultimate power the file triggers need to be in headers so that all
triggers are ready for action before the transaction starts, to avoid
unnecessary dependencies and ordering issues. And then you'll need semantics
for upgrade of a package co
On Fri, 5 Jun 2009, Ray Strode wrote:
Hi,
On Fri, Jun 5, 2009 at 2:05 PM, Adam Williamson wrote:
On Fri, 2009-06-05 at 13:50 -0400, Ray Strode wrote:
It seems to me it'd make sense to convert all these kinds of snippets
into macros. Am I right, or is there a reason against doing this?
It wo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nathanael D. Noblet wrote:
> Casey Dahlin wrote:
>> Nathanael D. Noblet wrote:
I don't know how hard it would be to fix rpm to allow for that though.
>>> Just off the top of my head, this doesn't feel like something rpm should
>>> be in charge of.
Hi,
On Fri, Jun 5, 2009 at 2:05 PM, Adam Williamson wrote:
> On Fri, 2009-06-05 at 13:50 -0400, Ray Strode wrote:
>
>> > It seems to me it'd make sense to convert all these kinds of snippets
>> > into macros. Am I right, or is there a reason against doing this?
>> It would be awesome to get rid of
On Fri, 2009-06-05 at 12:28 -0700, Toshio Kuratomi wrote:
> /me notes that we did pass it in the end, though.
>
> I don't believe this would be a problem for things like python_sitelib
> which are defining standard directory locations. using macros for
> directories is something that we do every
On Fri June 5 2009, Toshio Kuratomi wrote:
> For things that are replacing actions, there is a certain amount of
> obscuring being done. This is a barrier for entry for people who know
> how to build software from upstream but don't know how to package. It
> also can make debugging harder if som
On 06/05/2009 11:40 AM, Matthias Clasen wrote:
> On Fri, 2009-06-05 at 10:31 -0700, Adam Williamson wrote:
>
>>
>> It seems to me it'd make sense to convert all these kinds of snippets
>> into macros. Am I right, or is there a reason against doing this?
>>
>
> When this was discussed for the exam
On Fri, Jun 5, 2009 at 1:18 PM, Joe Nall wrote:
>
> On Jun 5, 2009, at 1:57 PM, Adam Williamson wrote:
>
>> On Fri, 2009-06-05 at 14:40 -0400, Matthias Clasen wrote:
>>>
>>> On Fri, 2009-06-05 at 10:31 -0700, Adam Williamson wrote:
>>>
It seems to me it'd make sense to convert all these k
On Jun 5, 2009, at 1:57 PM, Adam Williamson wrote:
On Fri, 2009-06-05 at 14:40 -0400, Matthias Clasen wrote:
On Fri, 2009-06-05 at 10:31 -0700, Adam Williamson wrote:
It seems to me it'd make sense to convert all these kinds of
snippets
into macros. Am I right, or is there a reason again
On 06/05/2009 11:59 AM, Adam Williamson wrote:
> On Fri, 2009-06-05 at 11:43 -0700, Toshio Kuratomi wrote:
>> The way to get these changed is to first go through the Packaging
>> Committee to get the changes approved, then have the macros merged into
>> the packages that will provide them. Then p
On Fri, 5 Jun 2009, Adam Williamson wrote:
On Fri, 2009-06-05 at 11:43 -0700, Toshio Kuratomi wrote:
To some extent, yes. macros can go overboard, though. I think that the
macros you're planning are going to make sense, though :-)
Thanks.
The way to get these changed is to first go thr
On Fri, 2009-06-05 at 11:43 -0700, Toshio Kuratomi wrote:
> To some extent, yes. macros can go overboard, though. I think that the
> macros you're planning are going to make sense, though :-)
Thanks.
> The way to get these changed is to first go through the Packaging
> Committee to get the cha
On Fri, 2009-06-05 at 14:40 -0400, Matthias Clasen wrote:
> On Fri, 2009-06-05 at 10:31 -0700, Adam Williamson wrote:
>
> >
> > It seems to me it'd make sense to convert all these kinds of snippets
> > into macros. Am I right, or is there a reason against doing this?
> >
>
> When this was discu
On 06/05/2009 10:31 AM, Adam Williamson wrote:
> It seems to me it'd make sense to convert all these kinds of snippets
> into macros. Am I right, or is there a reason against doing this?
>
> If I'm right, I'm happy to work on this and contribute it as patches to
> the relevant packages, or as a n
On Fri, 2009-06-05 at 10:31 -0700, Adam Williamson wrote:
>
> It seems to me it'd make sense to convert all these kinds of snippets
> into macros. Am I right, or is there a reason against doing this?
>
When this was discussed for the example of GConf schemas in the
packaging committee a few wee
Adam Williamson wrote:
> %{!?tcl_version: %global tcl_version %(echo 'puts $tcl_version' | tclsh)}
> %{!?tcl_sitelib: %global tcl_sitelib %{_datadir}/tcl%{tcl_version}}"
>
> %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from
> distutils.sysconfig import get_python_lib; print get_pyt
On Fri, 5 Jun 2009, Nathanael D. Noblet wrote:
[...]
It seems to me it'd make sense to convert all these kinds of snippets
into macros. Am I right, or is there a reason against doing this?
It would be awesome to get rid of the boilerplate. Honestly though,
I'd rather the solution was "jus
On Fri, 2009-06-05 at 13:50 -0400, Ray Strode wrote:
> > It seems to me it'd make sense to convert all these kinds of snippets
> > into macros. Am I right, or is there a reason against doing this?
> It would be awesome to get rid of the boilerplate. Honestly though,
> I'd rather the solution was
Casey Dahlin wrote:
Nathanael D. Noblet wrote:
I don't know how hard it would be to fix rpm to allow for that though.
Just off the top of my head, this doesn't feel like something rpm should
be in charge of. To me it seems more likely that we need something in a
base/core rpm that installs an i
Nathanael D. Noblet wrote:
>>
>> I don't know how hard it would be to fix rpm to allow for that though.
>
> Just off the top of my head, this doesn't feel like something rpm should
> be in charge of. To me it seems more likely that we need something in a
> base/core rpm that installs an inotify sc
Ray Strode wrote:
Hi,
On Fri, Jun 5, 2009 at 1:31 PM, Adam Williamson wrote:
I've been dipping my toes into packaging things for Fedora lately, and
one thing that feels a bit awkward is that the packaging guidelines are
full of boilerplate like:
[...]
Heck, there's an entire page full of thes
Hi,
On Fri, Jun 5, 2009 at 1:31 PM, Adam Williamson wrote:
> I've been dipping my toes into packaging things for Fedora lately, and
> one thing that feels a bit awkward is that the packaging guidelines are
> full of boilerplate like:
[...]
>
> Heck, there's an entire page full of these:
>
> https:
Just wanted to run this by the group to make sure it's desired before I
start working on it...
I've been dipping my toes into packaging things for Fedora lately, and
one thing that feels a bit awkward is that the packaging guidelines are
full of boilerplate like:
"Use this when a desktop entry ha
48 matches
Mail list logo
