Request to revert latest devicekit patch

Request to revert latest devicekit patch

[Holger Hans Peter Freyther]

Hi all,

9c5d1cb40bcb1d9412112bf73d7c7f4732989e89 was removing "-nonet" option from 
devicekit Makefiles. This means that everyone now needs to have internet 
connectivity to build devicekit, which I don't have most of the time.

Can anyone ack the revert please?

Re: Request to revert latest devicekit patch

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24-01-10 12:35, Holger Hans Peter Freyther wrote:
> Hi all,
> 
> 9c5d1cb40bcb1d9412112bf73d7c7f4732989e89 was removing "-nonet" option from 
> devicekit Makefiles. This means that everyone now needs to have internet 
> connectivity to build devicekit, which I don't have most of the time.
> 
> Can anyone ack the revert please?

The commit says:

Note: Another (maybe better) fix would be to package up docbook-xsl but
that is overkill for these two recipes.

Wouldn't that be a better option than introducing a regression?

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLXEGNMkyGM64RGpERAv7vAKCi1lVeVkrBrIf964XEJVmvM4YktgCeOkbq
OWDh9TD6uSnJkQnNLrOoxos=
=Jc7b
-----END PGP SIGNATURE-----

Re: Request to revert latest devicekit patch

[Stanislav Brabec]

Koen Kooi wrote:

> Note: Another (maybe better) fix would be to package up docbook-xsl but
> that is overkill for these two recipes.
> 
> Wouldn't that be a better option than introducing a regression?

Much more recipes could have benefit from working docbook recipes. For
example recipes/rhythmbox/rhythmbox_0.12.1.bb:

# FIXME: Native doc processing with xsltproc using docbook needs additional work:
do_configure_prepend() {
	sed -i '/^SUBDIRS/,/^$/s/help//' Makefile.am
}

I think that there is much more recipes that would be able to build some
documentation with working docbook3/4 and docbook-xsl.


________________________________________________________________________
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: Request to revert latest devicekit patch

[Rolf Leggewie]

Koen Kooi wrote:
> On 24-01-10 12:35, Holger Hans Peter Freyther wrote:
>> Can anyone ack the revert please?
> 
> The commit says:
> 
> Note: Another (maybe better) fix would be to package up docbook-xsl but
> that is overkill for these two recipes.

To introduce something new that patch breaks something for somebody else
that was previously working.  I thought it was commonly accepted that
it's then the author's (and possibly the committer's) responsibility to
come up with something better to fix this regression.

> Wouldn't that be a better option than introducing a regression?

The regression was introduced with the patch.  Not by reverting it.

A revert gets my ACK if this bothers Holger enough in his workflow.  I
would suggest Holger and David-John should talk about a time-frame in
which David-John can cook up a proper patch.  Based on this information
a decision should be made if a revert is necessary in the meantime or
not.  I trust Holger's judgment here.


PS: David-John, the whole discussion is at
http://thread.gmane.org/gmane.comp.handhelds.openembedded/29524

Re: Request to revert latest devicekit patch

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24-01-10 16:54, Rolf Leggewie wrote:
> Koen Kooi wrote:
>> On 24-01-10 12:35, Holger Hans Peter Freyther wrote:
>>> Can anyone ack the revert please?
>>
>> The commit says:
>>
>> Note: Another (maybe better) fix would be to package up docbook-xsl but
>> that is overkill for these two recipes.
> 
> To introduce something new that patch breaks something for somebody else
> that was previously working. 

That patch doesn't introduce anything new. It turns of an undocumented
dependency on host software.

We can argue what is better, to rely on stuff without documenting it or
to fetch missing stuff from the interwebs.

My preference would be to do as the commit message says and add the
missing recipe to OE, that would be a better way forward than breaking
one or the other.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLXHQqMkyGM64RGpERAj4dAJ49V6wQ1t/4Ie7bkD1zAOWIMesoEACfTQdX
/H84ncwWoyJiv85hKWqbYIk=
=TPfv
-----END PGP SIGNATURE-----

Re: Request to revert latest devicekit patch

[Rolf Leggewie]

Koen Kooi wrote:
> My preference would be to do as the commit message says and add the
> missing recipe to OE, that would be a better way forward than breaking
> one or the other.

Yes, I absolutely agree.

The question is who will do it.  As I indicated in my earlier mail, I
think it's best if David-John and Holger agree to a plan of action here.

Re: Request to revert latest devicekit patch

[John Willis]

Rolf,

Replying to your mail on-list.

As the author of said patch if people want it reverted go ahead. It has my
ACK.

> Koen Kooi wrote:
> > On 24-01-10 12:35, Holger Hans Peter Freyther wrote:
> >> Can anyone ack the revert please?
> >
> > The commit says:
> >
> > Note: Another (maybe better) fix would be to package up docbook-xsl
> but
> > that is overkill for these two recipes.
> 
> To introduce something new that patch breaks something for somebody
> else
> that was previously working.  I thought it was commonly accepted that
> it's then the author's (and possibly the committer's) responsibility to
> come up with something better to fix this regression.
> 
> > Wouldn't that be a better option than introducing a regression?
> 
> The regression was introduced with the patch.  Not by reverting it.
> 
> A revert gets my ACK if this bothers Holger enough in his workflow.  I
> would suggest Holger and David-John should talk about a time-frame in
> which David-John can cook up a proper patch.  Based on this information
> a decision should be made if a revert is necessary in the meantime or
> not.  I trust Holger's judgment here.
> 
> 
> PS: David-John, the whole discussion is at
> http://thread.gmane.org/gmane.comp.handhelds.openembedded/29524

As I stated in the original patch the correct fix is to sort out the
docbook-xsl packages but that was not something I had any intention at the
time to tackle (limited OE dev time and a seemingly infinite TODO list). I
may be able to look at it in the near future but as for being the best man
for the job, that I am not so sure about.

The sole reason for the patch was to fix a build failure on systems where
the host system docbook-xsl stuff was not available (or desired). 

Reverting the -nonet will reintroduce dependencies on components being
installed on the host system outside OE but if that is fine then go for the
revert. I understood (at the time, this is back in October) that depending
on host items outside oe's -native was a 'very bad thing' (tm) ;). Maybe
worse than requiring an internet connection but I am not the person to judge
that. 

I'll leave it to core OE devs to decide what is the lesser of 2 evils in
this case.

Regards,

John