pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Update pango to 1.29.4



On Tue, Jan 17, 2012 at 12:07:05AM +0100, Thomas Klausner wrote:
> On Mon, Jan 16, 2012 at 06:55:33PM +0000, Patrick Welche wrote:
> > Newish gtk3 needs pango >= 1.29.0, pango 1.29.5 needs glib >=2.31, so plump
> > for pango 1.29.4 which only needs glib >= 2.26.
> 
> You seem to be following the unstable branches here.
> GNOME is following the Linux convention that odd numbers are unstable and 
> even numbers are stable releases.

As a gnome developer, I am well aware of this ;-) I am trying to follow the
stable gtk3 3.2 series. As I write above however, it requires pango 1.29.

Now, all that might be "unstable" about pango 1.29 AFAICT is the new support
for CoreText. So, if we want to be conservative in pkgsrc, maybe the answer
is to pop the patch in as is, which would install the "old" atsui on darwin
and not touch the "unstable" coretext module? (Or we could just go for it ;-) )

> We try to avoid having the unstable versions in pkgsrc, so please wait for a 
> stable release before committing this.

I don't have commit access - otherwise pkg/45738, 45779, 45786, 45794, 45797,
45807, 45812 might already be in ;-) (If you think they are OK, maybe you
might consider giving me access?)

> > I not sure about the ABI_DEPENDS in buildlink3. I set it to 1.29.4. AFAICT
> > programs compiled against 1.28.4.nb2 are happy without needing to be
> > relinked, so is upping it necessary? API_DEPENDS correctly remains at 1.6.0.
> 
> Please read section 14.2.2 in the pgksrc guide and come back with any 
> questions :)

I had read it, and think I got the patch right...

> > I removed patch-aa as it risks making configure be regenerated, which isn't
> > necessary as it is already patched by patch-ab.
> 
> That patch can be sent upstream while patch-ab can't.
> Also, since the patches are applied alphabetically, configure should end up 
> with a newer timestamp.

Ah. (I feel that the patch is suspect though - which c++ compiler are the
non-gcc flags good for? Surely not everything apart from gcc? Then again,
that was accepted in the past.)

> > I have tested with the libthai option. I don't have access to darwin to
> > test that. In options.mk, there is reference to PLIST.carbon, but carbon
> > is not listed in PLIST_VARS - can that work? Is carbon defined elsewhere?
> > (I didn't find it in pkgsrc/mk)
> 
> /usr/pkgsrc/devel/pango/Makefile:PLIST_VARS+=           carbon
> /usr/pkgsrc/devel/pango/PLIST:${PLIST.carbon}include/pango-1.0/pango/pangoatsui.h

OK, that becomes a style question then: pop all the PLIST_VARS together in
Makefile, or in options.mk? (I would go for options.mk...)

> When was CoreText added to Mac OS X? If it's old enough, just make it
> default; if it's not old enough, make it optional default on and wait
> if a Mac OS X users complains :)

Agreed, unless the "be conservative in pkgsrc" argument prevails? (ie the
difference between an even and an odd number being CoreText)

Cheers,

Patrick


Home | Main Index | Thread Index | Old Index