Bug 148294 - Update opera and opera-linuxplugins to 10.60
Summary: Update opera and opera-linuxplugins to 10.60
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Dirk Meyer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-01 15:30 UTC by Arjan van Leeuwen
Modified: 2010-08-14 05:20 UTC (History)
1 user (show)

See Also:


Attachments
opera.diff (20.68 KB, patch)
2010-07-01 15:30 UTC, Arjan van Leeuwen
no flags Details | Diff
file.diff (2.84 KB, patch)
2010-07-01 15:30 UTC, Arjan van Leeuwen
no flags Details | Diff
opera.diff (20.73 KB, patch)
2010-07-09 16:06 UTC, Arjan van Leeuwen
no flags Details | Diff
opera.diff (21.02 KB, patch)
2010-07-12 17:41 UTC, arjanl
no flags Details | Diff
opera.patch (22.10 KB, patch)
2010-07-19 11:59 UTC, Veniamin
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Arjan van Leeuwen 2010-07-01 15:30:10 UTC

This patch updates www/opera and www/opera-linuxplugins to version 10.60.

Changelog: http://www.opera.com/docs/changelogs/unix/1060/
Comment 1 Ion-Mihai "IOnut" Tetcu freebsd_committer freebsd_triage 2010-07-01 16:16:00 UTC
Responsible Changed
From-To: freebsd-ports-bugs->itetcu

I'll take it.
Comment 2 Ion-Mihai "IOnut" Tetcu freebsd_committer freebsd_triage 2010-07-02 12:35:57 UTC
State Changed
From-To: open->feedback

Leaving apart wrong plist and such, on my 8-STABLE-amd64 it crashes when 
I close it (even with vanilla ~/.opera). It also looses customizations 
of the interface; and at least for my 4 windows with many tabs, it 
freezes.
Comment 3 Arjan van Leeuwen 2010-07-05 09:38:26 UTC
Let me know what's wrong with the plist. The other things mentioned are  
bugs in Opera, not in the port - they can't be fixed by changing the port.  
Feel free to file them as bugs at https://bugs.opera.com/wizard/.

However, bugs that are found in Opera in your particular environment  
shouldn't stop others from receiving this update to their port.
Comment 4 poyopoyo 2010-07-08 00:00:49 UTC
Hi Arjan,

> +share/applications/mimeinfo.cache

This is generated file by update-desktop-database command run by Opera
install script and shouldn't be included in pkg-plist. When you don't
have desktop-file-utils package it does not created in the first place
and leads to fail packaging.

So, I think you would want to put:
@unexec %%LOCALBASE%%/bin/update-desktop-database > /dev/null || /usr/bin/true
to the last line of pkg-plist like some ports do. It looks to be The
FreeBSD Way; 173 other ports do this.

By the way, the install script explicitly prevents us installing on
9-CURRENT with case statement:

|   FreeBSD\ [78].*)

This is not good, as FreeBSD 9 is designed to run older binary
flawlessly (in the ideal world. :-) I hope that to be [7-9].

itetcu,

I too have 10.60 dumping core at every exit on -CURRENT/amd64
too. Though, nice to hear this is not only a -CURRENT issue but also
happened on 8-STABLE.

-- 
kuro
Comment 5 Arjan van Leeuwen 2010-07-09 16:06:27 UTC
Hi kuro,

Thanks for the help. The attached patch (which replaces the previous  
patch) forces the install of Opera to make it possible to install the port  
on newer versions of FreeBSD as well (the port should check for the  
FreeBSD version, not the installer) and uses update-desktop-database.

With regard to both your Operas crashing on exit: we have a bug report in  
our database that reports this happens in Opera for FreeBSD when using the  
GTK UI backend in desktop environments other than Gnome. You can try if  
this is the case by either running Opera in Gnome (if you are not right  
now), or by forcing the UI backend to pure X11 or KDE (by setting  
opera:config#FileSelector|DialogToolkit to 4 or 3, respectively). You can  
see which UI backend Opera uses by running 'opera --full-version'.

Arjan

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Comment 6 poyopoyo 2010-07-10 14:15:59 UTC
Hi Arjan,

Thanks for a tip and new patch. It install/package/deinstalls
flawlessly on my 9-CURRENT/amd64 now.

With
| [File Selector]
| Dialog Toolkit=4
running X11 toolkit it no longer crashes at exit. For me both =3 and =2,
KDE4 and GTK2 crashes, perhaps because I don't run KDE4, or GNOME
either. What an old-timer I am. The X11 is enough for me.

Unlike previous versions, Opera now depends on outside supplied
toolkit libraries such as libQtWhatever/libkXYZ or libgtk-something so this
port should register dependencies on them (selectable through OPTIONS
is nice.)

And it might help to add an UPDATING entry, describing crash-at-exit
issue with unfamiliar toolkits and workaround for it.

By the way, it is truly incredible speed-up what the Opera 10.60
achieves to provide. No other web browsers required; I've lived with
Opera and can't live without it any more.

-- 
kuro
Comment 7 arjanl 2010-07-10 19:56:44 UTC
Op Sat, 10 Jul 2010 15:15:59 +0200 schreef <poyopoyo@puripuri.plala.or.jp>:

> Hi Arjan,
>
> Thanks for a tip and new patch. It install/package/deinstalls
> flawlessly on my 9-CURRENT/amd64 now.
>
> With
> | [File Selector]
> | Dialog Toolkit=4
> running X11 toolkit it no longer crashes at exit. For me both =3 and =2,
> KDE4 and GTK2 crashes, perhaps because I don't run KDE4, or GNOME
> either. What an old-timer I am. The X11 is enough for me.
>
> Unlike previous versions, Opera now depends on outside supplied
> toolkit libraries such as libQtWhatever/libkXYZ or libgtk-something so  
> this
> port should register dependencies on them (selectable through OPTIONS
> is nice.)

I thought about that, but it doesn't really depend on them. There's no  
preset choice on installation, Opera will autoselect a backend depending  
on your currently running desktop environment and available libraries. So  
it won't stop working if you deinstall all KDE and GTK libraries, for  
example, even if you are running KDE or GTK. And if you are running Opera  
in Gnome right now but later switch to KDE, Opera will load the KDE  
backend on startup.

> And it might help to add an UPDATING entry, describing crash-at-exit
> issue with unfamiliar toolkits and workaround for it.
>
> By the way, it is truly incredible speed-up what the Opera 10.60
> achieves to provide. No other web browsers required; I've lived with
> Opera and can't live without it any more.

Good to hear :)

Arjan


-- 
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
Comment 8 Alex Kozlov 2010-07-12 06:20:59 UTC
Sat, 10 Jul 2010 20:56:44 +0200 Arjan van Leeuwen wrote:

> I thought about that, but it doesn't really depend on them. There's no 
> preset choice on installation, Opera will autoselect a backend depending 
> on your currently running desktop environment and available libraries. So 
> it won't stop working if you deinstall all KDE and GTK libraries, for 
> example, even if you are running KDE or GTK. And if you are running Opera 
> in Gnome right now but later switch to KDE, Opera will load the KDE 
> backend on startup.
I still think that at least the basic dependencies should be added:
USE_XORG=x11 xext sm ice xft xrender

LIB_DEPENDS=	freetype.9:${PORTSDIR}/print/freetype2 \
		fontconfig.1:${PORTSDIR}/x11-fonts/fontconfig

Also optional dependencies for kde/qt backend would be good thing.

p.s. Are You sure that 10.60 ready for prime time? I test it only for a few hours and
already got a few nasty regressions.
First - without qt opera can't parse /etc/printcap and as a result there is no printer.
Workaround from 9.x with PrinterCustomName/PrinterCustomParameter also doesn't work.
Second - weird problem with copy/paste. Some pages work ok(http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/148294) but from others paste don't work at all(http://google.com)


--
Adios
Comment 9 arjanl 2010-07-12 17:41:31 UTC
On Mon, 12 Jul 2010 07:20:59 +0200, Alex Kozlov <spam@rm-rf.kiev.ua> wrote:

> Sat, 10 Jul 2010 20:56:44 +0200 Arjan van Leeuwen wrote:
>
>> I thought about that, but it doesn't really depend on them. There's no
>> preset choice on installation, Opera will autoselect a backend depending
>> on your currently running desktop environment and available libraries.  
>> So
>> it won't stop working if you deinstall all KDE and GTK libraries, for
>> example, even if you are running KDE or GTK. And if you are running  
>> Opera
>> in Gnome right now but later switch to KDE, Opera will load the KDE
>> backend on startup.
> I still think that at least the basic dependencies should be added:
> USE_XORG=x11 xext sm ice xft xrender
>
> LIB_DEPENDS=	freetype.9:${PORTSDIR}/print/freetype2 \
> 		fontconfig.1:${PORTSDIR}/x11-fonts/fontconfig

You're right, it should have those. Added in the attached patch. As far as  
I can see that fulfills all the library requirements (ie. all the  
libraries Opera links to).

> Also optional dependencies for kde/qt backend would be good thing.

I'm still not convinced this is a good thing, because I'd say that a  
dependency means that something stops working when the dependency is  
removed. That is not the case here (even if you have a dependency on KDE,  
Opera will keep working fine if you remove it). Also the other way around:  
if you only select a dependency on KDE but later install GTK and run  
Gnome, it will use GTK and thus 'depend' on that (but nothing you can  
change in the port registration at that stage).

> p.s. Are You sure that 10.60 ready for prime time? I test it only for a  
> few hours and
> already got a few nasty regressions.

10.6 is a really big change from previous Opera Unix releases, so I would  
expect some bugs to be found. Of course this build has gone through  
extensive QA, but quite less so on FreeBSD compared to Linux, and there's  
also a lot less user testing on FreeBSD (ie. we get almost no bug reports  
for our weekly snapshots from FreeBSD users). The results of that would  
mostly be seen in configurations that are more 'custom' than others (not  
using well-known desktop environments etc).

> First - without qt opera can't parse /etc/printcap and as a result there  
> is no printer.
> Workaround from 9.x with PrinterCustomName/PrinterCustomParameter also  
> doesn't work.

 From 10.6 on, Opera needs Cups to do printing. I've updated the port to  
reflect that. Without Cups, you can only print to file.

> Second - weird problem with copy/paste. Some pages work  
> ok(http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/148294) but from  
> others paste don't work at all(http://google.com)

This is something that is better suited for entering into the bug system:  
https://bugs.opera.com/wizard/

Thanks,

Arjan

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Comment 10 Alex Kozlov 2010-07-12 19:26:14 UTC
On Mon, Jul 12, 2010 at 06:41:31PM +0200, Arjan van Leeuwen wrote:
> On Mon, 12 Jul 2010 07:20:59 +0200, Alex Kozlov <spam@rm-rf.kiev.ua> wrote:
> > Sat, 10 Jul 2010 20:56:44 +0200 Arjan van Leeuwen wrote:

> > Also optional dependencies for kde/qt backend would be good thing.
> I'm still not convinced this is a good thing, because I'd say that a  
> dependency means that something stops working when the dependency is  
> removed. That is not the case here (even if you have a dependency on KDE,  
> Opera will keep working fine if you remove it). Also the other way around:  
> if you only select a dependency on KDE but later install GTK and run  
> Gnome, it will use GTK and thus 'depend' on that (but nothing you can  
> change in the port registration at that stage).
Keyword is optional. For example, they help in case when user want to try
specific backend and dependencies for it not present.

> > p.s. Are You sure that 10.60 ready for prime time? I test it only for a  
> > few hours and already got a few nasty regressions.
> 10.6 is a really big change from previous Opera Unix releases, so I would  
> expect some bugs to be found. Of course this build has gone through  
> extensive QA, but quite less so on FreeBSD compared to Linux, and there's  
> also a lot less user testing on FreeBSD (ie. we get almost no bug reports  
> for our weekly snapshots from FreeBSD users). The results of that would  
> mostly be seen in configurations that are more 'custom' than others (not  
> using well-known desktop environments etc).
Don't get me wrong, 10.6x have potential to be a great release, but
as You say, it still rough and unpolished, so may be better to leave
www/opera at 10.10 for now and commit this patch to www/opera-devel?
 
> > First - without qt opera can't parse /etc/printcap and as a result there  
> > is no printer.
> > Workaround from 9.x with PrinterCustomName/PrinterCustomParameter also  
> > doesn't work.
>  From 10.6 on, Opera needs Cups to do printing. I've updated the port to  
> reflect that. Without Cups, you can only print to file.
It's strange decision, especially for bsd platform. But this can be easily
solved by adding possibility to specify pipe instead of file. I.e.
'|lpr' instead of /path/filename in Print to file.

> > Second - weird problem with copy/paste. Some pages work  
> > ok(http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/148294) but from  
> > others paste don't work at all(http://google.com)
> This is something that is better suited for entering into the bug system:  
> https://bugs.opera.com/wizard/
I will try latter. Also I have problem with fonts reseting to *Mono and
many graphical glitches.


--
Adios
Comment 11 arjanl 2010-07-12 21:24:56 UTC
Op Mon, 12 Jul 2010 20:26:14 +0200 schreef Alex Kozlov  
<spam@rm-rf.kiev.ua>:

> On Mon, Jul 12, 2010 at 06:41:31PM +0200, Arjan van Leeuwen wrote:
>> On Mon, 12 Jul 2010 07:20:59 +0200, Alex Kozlov <spam@rm-rf.kiev.ua>  
>> wrote:
>> > Sat, 10 Jul 2010 20:56:44 +0200 Arjan van Leeuwen wrote:
>
>> > Also optional dependencies for kde/qt backend would be good thing.
>> I'm still not convinced this is a good thing, because I'd say that a
>> dependency means that something stops working when the dependency is
>> removed. That is not the case here (even if you have a dependency on  
>> KDE,
>> Opera will keep working fine if you remove it). Also the other way  
>> around:
>> if you only select a dependency on KDE but later install GTK and run
>> Gnome, it will use GTK and thus 'depend' on that (but nothing you can
>> change in the port registration at that stage).
>
> Keyword is optional. For example, they help in case when user want to try
> specific backend and dependencies for it not present.

In that case I don't know enough about the FreeBSD ports system to make  
this decision, and would like to ask a FreeBSD ports committer to speak  
up. FWIW, on Debian we use the 'suggests' field for this.

>> > p.s. Are You sure that 10.60 ready for prime time? I test it only for  
>> a
>> > few hours and already got a few nasty regressions.
>> 10.6 is a really big change from previous Opera Unix releases, so I  
>> would
>> expect some bugs to be found. Of course this build has gone through
>> extensive QA, but quite less so on FreeBSD compared to Linux, and  
>> there's
>> also a lot less user testing on FreeBSD (ie. we get almost no bug  
>> reports
>> for our weekly snapshots from FreeBSD users). The results of that would
>> mostly be seen in configurations that are more 'custom' than others (not
>> using well-known desktop environments etc).
>
> Don't get me wrong, 10.6x have potential to be a great release, but
> as You say, it still rough and unpolished, so may be better to leave
> www/opera at 10.10 for now and commit this patch to www/opera-devel?

I didn't say it was rough and unpolished. Having it as opera-devel is not  
an option. Apart from being wrong (10.60 is the current final release,  
there are snapshots out that qualify as opera-devel) it puts users at risk  
- 10.60 also fixes security issues.

Arjan


-- 
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
Comment 12 Alex Kozlov 2010-07-13 07:02:48 UTC
On Mon, Jul 12, 2010 at 10:24:56PM +0200, Arjan van Leeuwen wrote:
> Op Mon, 12 Jul 2010 20:26:14 +0200 schreef Alex Kozlov  wrote:
> > On Mon, Jul 12, 2010 at 06:41:31PM +0200, Arjan van Leeuwen wrote:
> >> On Mon, 12 Jul 2010 07:20:59 +0200, Alex Kozlov wrote:
> >> > Sat, 10 Jul 2010 20:56:44 +0200 Arjan van Leeuwen wrote:

> >> > Also optional dependencies for kde/qt backend would be good thing.
> >> I'm still not convinced this is a good thing, because I'd say that a
> >> dependency means that something stops working when the dependency is
> >> removed. That is not the case here (even if you have a dependency on  
> >> KDE, Opera will keep working fine if you remove it). Also the other way  
> >> around: if you only select a dependency on KDE but later install GTK
> >> and run Gnome, it will use GTK and thus 'depend' on that (but nothing
> >> you can change in the port registration at that stage).
> > Keyword is optional. For example, they help in case when user want to try
> > specific backend and dependencies for it not present.
> In that case I don't know enough about the FreeBSD ports system to
> make this decision, and would like to ask a FreeBSD ports committer to
> speak up. FWIW, on Debian we use the 'suggests' field for this.
Something like this would be enough, I believe:

OPTIONS=    GTK "Use GTK backend" off \
            QT  "Use KDE backend" off

.include <bsd.port.pre.mk>

.ifdef WITH_GTK
USE_GNOME=  atk glib20 gtk20 pango
USE_XORG+=  xcomposite xcursor xdamage xfixes xi xinerama
LIB_DEPENDS+=   cairo.2:${PORTSDIR}/graphics/cairo
.endif

.ifdef WITH_KDE
USE_KDE4=   kdelibs
USE_QT_VER= 4
QT_COMPONENTS=  corelib gui
.endif


--
Adios
Comment 13 arjanl 2010-07-13 08:40:14 UTC
Op Tue, 13 Jul 2010 08:02:48 +0200 schreef Alex Kozlov  
<spam@rm-rf.kiev.ua>:

> On Mon, Jul 12, 2010 at 10:24:56PM +0200, Arjan van Leeuwen wrote:
>> Op Mon, 12 Jul 2010 20:26:14 +0200 schreef Alex Kozlov  wrote:
>> > On Mon, Jul 12, 2010 at 06:41:31PM +0200, Arjan van Leeuwen wrote:
>> >> On Mon, 12 Jul 2010 07:20:59 +0200, Alex Kozlov wrote:
>> >> > Sat, 10 Jul 2010 20:56:44 +0200 Arjan van Leeuwen wrote:
>
>> >> > Also optional dependencies for kde/qt backend would be good thing.
>> >> I'm still not convinced this is a good thing, because I'd say that a
>> >> dependency means that something stops working when the dependency is
>> >> removed. That is not the case here (even if you have a dependency on
>> >> KDE, Opera will keep working fine if you remove it). Also the other  
>> way
>> >> around: if you only select a dependency on KDE but later install GTK
>> >> and run Gnome, it will use GTK and thus 'depend' on that (but nothing
>> >> you can change in the port registration at that stage).
>> > Keyword is optional. For example, they help in case when user want to  
>> try
>> > specific backend and dependencies for it not present.
>> In that case I don't know enough about the FreeBSD ports system to
>> make this decision, and would like to ask a FreeBSD ports committer to
>> speak up. FWIW, on Debian we use the 'suggests' field for this.
> Something like this would be enough, I believe:
>
> OPTIONS=    GTK "Use GTK backend" off \
>             QT  "Use KDE backend" off
>
> .include <bsd.port.pre.mk>
>
> .ifdef WITH_GTK
> USE_GNOME=  atk glib20 gtk20 pango
> USE_XORG+=  xcomposite xcursor xdamage xfixes xi xinerama
> LIB_DEPENDS+=   cairo.2:${PORTSDIR}/graphics/cairo
> .endif
>
> .ifdef WITH_KDE
> USE_KDE4=   kdelibs
> USE_QT_VER= 4
> QT_COMPONENTS=  corelib gui
> .endif

Yes, I understand how to do this. But I want to know whether it is the  
right thing to do from Ion-Mihai.

Arjan


-- 
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
Comment 14 ionut 2010-07-13 10:12:00 UTC
On Tue, 13 Jul 2010 09:40:14 +0200
"Arjan van Leeuwen" <arjanl@opera.com> wrote:

> Op Tue, 13 Jul 2010 08:02:48 +0200 schreef Alex Kozlov  
> <spam@rm-rf.kiev.ua>:
> 
> > On Mon, Jul 12, 2010 at 10:24:56PM +0200, Arjan van Leeuwen wrote:
> >> Op Mon, 12 Jul 2010 20:26:14 +0200 schreef Alex Kozlov  wrote:
> >> > On Mon, Jul 12, 2010 at 06:41:31PM +0200, Arjan van Leeuwen wrote:
> >> >> On Mon, 12 Jul 2010 07:20:59 +0200, Alex Kozlov wrote:
> >> >> > Sat, 10 Jul 2010 20:56:44 +0200 Arjan van Leeuwen wrote:
> >
> >> >> > Also optional dependencies for kde/qt backend would be good thing.
> >> >> I'm still not convinced this is a good thing, because I'd say that a
> >> >> dependency means that something stops working when the dependency is
> >> >> removed. That is not the case here (even if you have a dependency on
> >> >> KDE, Opera will keep working fine if you remove it). Also the other  
> >> way
> >> >> around: if you only select a dependency on KDE but later install GTK
> >> >> and run Gnome, it will use GTK and thus 'depend' on that (but nothing
> >> >> you can change in the port registration at that stage).
> >> > Keyword is optional. For example, they help in case when user want to  
> >> try
> >> > specific backend and dependencies for it not present.
> >> In that case I don't know enough about the FreeBSD ports system to
> >> make this decision, and would like to ask a FreeBSD ports committer to
> >> speak up. FWIW, on Debian we use the 'suggests' field for this.
> > Something like this would be enough, I believe:
> >
> > OPTIONS=    GTK "Use GTK backend" off \
> >             QT  "Use KDE backend" off
> >
> > .include <bsd.port.pre.mk>
> >
> > .ifdef WITH_GTK
> > USE_GNOME=  atk glib20 gtk20 pango
> > USE_XORG+=  xcomposite xcursor xdamage xfixes xi xinerama
> > LIB_DEPENDS+=   cairo.2:${PORTSDIR}/graphics/cairo
> > .endif
> >
> > .ifdef WITH_KDE
> > USE_KDE4=   kdelibs
> > USE_QT_VER= 4
> > QT_COMPONENTS=  corelib gui
> > .endif
> 
> Yes, I understand how to do this. But I want to know whether it is the  
> right thing to do from Ion-Mihai.

I'm currrently in Brazil for a bit of relaxation and a talk at a
conference. I asked miwi@ to handle this PR, since my internet access
is very spotty and I'll return home only at the end of the month.


-- 
Ion-Mihai Tetcu <ionut@tetcu.info>
Comment 15 Veniamin 2010-07-19 11:59:09 UTC
Veniamin Gvozdikov---------------| OpenPGP
-------------------------------------------
OpenPGP for this is e-mail adress| 9B9E5154
XMMP: zloidemon(at)jabber(dot)ru | 19B4A605
Comment 16 Arjan van Leeuwen 2010-07-21 10:17:29 UTC
Hi Martin, can you help with this? See below:

On Tue, 13 Jul 2010 11:12:00 +0200, Ion-Mihai Tetcu <ionut@tetcu.info>  
wrote:

> On Tue, 13 Jul 2010 09:40:14 +0200
> "Arjan van Leeuwen" <arjanl@opera.com> wrote:
>
>> Op Tue, 13 Jul 2010 08:02:48 +0200 schreef Alex Kozlov
>> <spam@rm-rf.kiev.ua>:
>>
>> > On Mon, Jul 12, 2010 at 10:24:56PM +0200, Arjan van Leeuwen wrote:
>> >> Op Mon, 12 Jul 2010 20:26:14 +0200 schreef Alex Kozlov  wrote:
>> >> > On Mon, Jul 12, 2010 at 06:41:31PM +0200, Arjan van Leeuwen wrote:
>> >> >> On Mon, 12 Jul 2010 07:20:59 +0200, Alex Kozlov wrote:
>> >> >> > Sat, 10 Jul 2010 20:56:44 +0200 Arjan van Leeuwen wrote:
>> >
>> >> >> > Also optional dependencies for kde/qt backend would be good  
>> thing.
>> >> >> I'm still not convinced this is a good thing, because I'd say  
>> that a
>> >> >> dependency means that something stops working when the dependency  
>> is
>> >> >> removed. That is not the case here (even if you have a dependency  
>> on
>> >> >> KDE, Opera will keep working fine if you remove it). Also the  
>> other
>> >> way
>> >> >> around: if you only select a dependency on KDE but later install  
>> GTK
>> >> >> and run Gnome, it will use GTK and thus 'depend' on that (but  
>> nothing
>> >> >> you can change in the port registration at that stage).
>> >> > Keyword is optional. For example, they help in case when user want  
>> to
>> >> try
>> >> > specific backend and dependencies for it not present.
>> >> In that case I don't know enough about the FreeBSD ports system to
>> >> make this decision, and would like to ask a FreeBSD ports committer  
>> to
>> >> speak up. FWIW, on Debian we use the 'suggests' field for this.
>> >
>> > Something like this would be enough, I believe:
>> >
>> > OPTIONS=    GTK "Use GTK backend" off \
>> >             QT  "Use KDE backend" off
>> >
>> > .include <bsd.port.pre.mk>
>> >
>> > .ifdef WITH_GTK
>> > USE_GNOME=  atk glib20 gtk20 pango
>> > USE_XORG+=  xcomposite xcursor xdamage xfixes xi xinerama
>> > LIB_DEPENDS+=   cairo.2:${PORTSDIR}/graphics/cairo
>> > .endif
>> >
>> > .ifdef WITH_KDE
>> > USE_KDE4=   kdelibs
>> > USE_QT_VER= 4
>> > QT_COMPONENTS=  corelib gui
>> > .endif
>>
>> Yes, I understand how to do this. But I want to know whether it is the
>> right thing to do from Ion-Mihai.
>
> I'm currrently in Brazil for a bit of relaxation and a talk at a
> conference. I asked miwi@ to handle this PR, since my internet access
> is very spotty and I'll return home only at the end of the month.
>
>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Comment 17 Ion-Mihai "IOnut" Tetcu freebsd_committer freebsd_triage 2010-08-07 17:30:33 UTC
Responsible Changed
From-To: itetcu->freebsd-ports-bugs

release this PR. IMO this version is unusable, at least in my 
environment, so I won't commit it.
Comment 18 Dirk Meyer freebsd_committer freebsd_triage 2010-08-13 11:48:46 UTC
Responsible Changed
From-To: freebsd-ports-bugs->dinoex

I will take care of it.
Comment 19 dfilter service freebsd_committer freebsd_triage 2010-08-13 13:21:26 UTC
dinoex      2010-08-13 12:21:17 UTC

  FreeBSD ports repository

  Modified files:
    www/opera            Makefile distinfo pkg-plist 
    www/opera/files      operapluginwrapper patch-install.sh 
  Log:
  - update to 10.61
  PR:             148294
  PR:             148818
  Sumitted by:    Arjan van Leeuwen
  
  Revision  Changes    Path
  1.93      +71 -39    ports/www/opera/Makefile
  1.62      +6 -12     ports/www/opera/distinfo
  1.7       +0 -2      ports/www/opera/files/operapluginwrapper
  1.28      +0 -19     ports/www/opera/files/patch-install.sh
  1.39      +170 -25   ports/www/opera/pkg-plist
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Comment 20 dfilter service freebsd_committer freebsd_triage 2010-08-13 14:19:39 UTC
dinoex      2010-08-13 13:19:26 UTC

  FreeBSD ports repository

  Modified files:
    www/opera-linuxplugins Makefile distinfo 
  Log:
  - update to 10.61
  PR:             148294
  PR:             148819
  Submitted by:   Arjan van Leeuwen
  
  Revision  Changes    Path
  1.14      +8 -13     ports/www/opera-linuxplugins/Makefile
  1.8       +3 -3      ports/www/opera-linuxplugins/distinfo
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Comment 21 Dirk Meyer freebsd_committer freebsd_triage 2010-08-13 14:40:32 UTC
State Changed
From-To: feedback->closed

committed with small plist changes and 10.61 distribution, thanks.
Comment 22 dfilter service freebsd_committer freebsd_triage 2010-08-14 05:12:13 UTC
dinoex      2010-08-14 04:11:59 UTC

  FreeBSD ports repository

  Removed files:
    www/opera/files      patch-install.sh 
  Log:
  - remove empty file
  Reported by:    Matthew D. Fuller
  PR:             148294
  
  Revision  Changes    Path
  1.29      +0 -0      ports/www/opera/files/patch-install.sh (dead)
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"