Style issue for recipes

Style issue for recipes

[Burton, Ross]

Hi,

Quick question of style for the community to bikeshed on:  in the
general case should recipes be split into foo_1.2.bb and foo.inc, or
should they only split to bb/inc if there are multiple versions and
generally there should just be foo_1.2.bb.

Specifically I'm looking at the libunwind patch for oe-core (moving
from meta-oe) which adds libunwind_1.1.bb and libunwind.inc.
Personally I feel that splitting them up complicates packaging and
should only be done if there's actually multiple versions being used.

Ross

Re: [oe] Style issue for recipes

[Robert Yang]

On 09/04/2014 10:12 PM, Burton, Ross wrote:
> Hi,
>
> Quick question of style for the community to bikeshed on:  in the
> general case should recipes be split into foo_1.2.bb and foo.inc, or
> should they only split to bb/inc if there are multiple versions and
> generally there should just be foo_1.2.bb.

I think that put the constants in .inc is helpful for upgrading, for
example, the SUMMARY, DESCRIPTION, HOMEPAGE, SECTION, inherit and so on,
they are unlikely to change when upgrade.

// Robert

>
> Specifically I'm looking at the libunwind patch for oe-core (moving
> from meta-oe) which adds libunwind_1.1.bb and libunwind.inc.
> Personally I feel that splitting them up complicates packaging and
> should only be done if there's actually multiple versions being used.
>
> Ross
>

Re: [oe] Style issue for recipes

[akuster808]

On 09/04/2014 08:03 AM, Robert Yang wrote:
>
> On 09/04/2014 10:12 PM, Burton, Ross wrote:
>> Hi,
>>
>> Quick question of style for the community to bikeshed on:  in the
>> general case should recipes be split into foo_1.2.bb and foo.inc, or
>> should they only split to bb/inc if there are multiple versions and
>> generally there should just be foo_1.2.bb.
>
> I think that put the constants in .inc is helpful for upgrading, for
> example, the SUMMARY, DESCRIPTION, HOMEPAGE, SECTION, inherit and so on,
> they are unlikely to change when upgrade.

This is the same reason why I have split a bb into two parts when I 
submit upgrades. I feel it makes reviewing easier the next time a 
package gets upgraded. Trying to find the actual changes between a file 
being deleted and the new one being added might lead to missing something.

If there are unintentional consequence by doing this, that is a problem.

- Armin

> // Robert
>
>>
>> Specifically I'm looking at the libunwind patch for oe-core (moving
>> from meta-oe) which adds libunwind_1.1.bb and libunwind.inc.
>> Personally I feel that splitting them up complicates packaging and
>> should only be done if there's actually multiple versions being used.
>>
>> Ross
>>

Re: [oe] Style issue for recipes

[Burton, Ross]

On 4 September 2014 16:41, akuster808 <akuster808@gmail.com> wrote:
> This is the same reason why I have split a bb into two parts when I submit
> upgrades. I feel it makes reviewing easier the next time a package gets
> upgraded. Trying to find the actual changes between a file being deleted and
> the new one being added might lead to missing something.
>
> If there are unintentional consequence by doing this, that is a problem.

This is what git format-patch -M is for: it detects the rename and
shows a "proper" diff.

Ross

Re: [oe] Style issue for recipes

[akuster808]

On 09/04/2014 09:26 AM, Burton, Ross wrote:
> On 4 September 2014 16:41, akuster808 <akuster808@gmail.com> wrote:
>> This is the same reason why I have split a bb into two parts when I submit
>> upgrades. I feel it makes reviewing easier the next time a package gets
>> upgraded. Trying to find the actual changes between a file being deleted and
>> the new one being added might lead to missing something.
>>
>> If there are unintentional consequence by doing this, that is a problem.
>
> This is what git format-patch -M is for: it detects the rename and
> shows a "proper" diff.
>
Ah, that is what -M does. That negates my concern.

thanks for the info.

- Armin
> Ross
>

Re: [oe] Style issue for recipes

[Enrico Scholz]

"Burton, Ross" <ross.burton@intel.com> writes:

> Quick question of style for the community to bikeshed on: in the
> general case should recipes be split into foo_1.2.bb and foo.inc, or
> should they only split to bb/inc if there are multiple versions and
> generally there should just be foo_1.2.bb.
>
> Specifically I'm looking at the libunwind patch for oe-core (moving
> from meta-oe) which adds libunwind_1.1.bb and libunwind.inc.
> Personally I feel that splitting them up complicates packaging and
> should only be done if there's actually multiple versions being used.

.inc files make sense with current packaging because they are revision
control friendly.  E.g. you can put the logic into .inc and follow its
history with 'git log' which is not possible when there are only the
versioned .bb files.

Of course, the versioned .bb files do not make much sense nowadays.
They were useful in old OE times were multiple versions of a package
were kept in parallel.



Enrico

Re: [oe] Style issue for recipes

[Burton, Ross]

On 4 September 2014 17:07, Enrico Scholz
<enrico.scholz@sigma-chemnitz.de> wrote:
> .inc files make sense with current packaging because they are revision
> control friendly.  E.g. you can put the logic into .inc and follow its
> history with 'git log' which is not possible when there are only the
> versioned .bb files.

You can follow changes to the .inc but not anything that went in and
out of the .bb, but I do concede that git not tracking the renames
directly does mean some histories are harder to track (although simple
to follow as the commit where the history stops will tell you where to
pick it up again).

Ross

Re: [oe] Style issue for recipes

[Peter A. Bigot]

On 09/04/2014 11:29 AM, Burton, Ross wrote:
> On 4 September 2014 17:07, Enrico Scholz
> <enrico.scholz@sigma-chemnitz.de> wrote:
>> .inc files make sense with current packaging because they are revision
>> control friendly.  E.g. you can put the logic into .inc and follow its
>> history with 'git log' which is not possible when there are only the
>> versioned .bb files.
> You can follow changes to the .inc but not anything that went in and
> out of the .bb, but I do concede that git not tracking the renames
> directly does mean some histories are harder to track (although simple
> to follow as the commit where the history stops will tell you where to
> pick it up again).

git log --follow foo_1.2.bb handles 90% of this:

       --follow
            Continue listing the history of a file beyond renames (works 
only for a single file).

E.g. you can go all the way back to systemd 196 with:

     git log --follow meta/recipes-core/systemd/systemd_216.bb

Peter

Re: [oe] Style issue for recipes

[Enrico Scholz]

"Peter A. Bigot" <pab@pabigot.com> writes:

>>> .inc files make sense with current packaging because they are revision
>>> control friendly.  E.g. you can put the logic into .inc and follow its
>>> history with 'git log' which is not possible when there are only the
>>> versioned .bb files.
>> You can follow changes to the .inc but not anything that went in and
>> out of the .bb, but I do concede that git not tracking the renames
>> directly does mean some histories are harder to track (although simple
>> to follow as the commit where the history stops will tell you where to
>> pick it up again).
>
> git log --follow foo_1.2.bb handles 90% of this:

it's not only 'git log'; it is 'git blame' too and because git does not
support renaming of files natively, the 'git log --follow' method is
error prone and might compare the wrong files resp. fail completely when
there are too much changes.


Enrico

Re: [oe] Style issue for recipes

[Andreas Müller]

On Thu, Sep 4, 2014 at 7:00 PM, Enrico Scholz
<enrico.scholz@sigma-chemnitz.de> wrote:
> "Peter A. Bigot" <pab@pabigot.com> writes:
>
>>>> .inc files make sense with current packaging because they are revision
>>>> control friendly.  E.g. you can put the logic into .inc and follow its
>>>> history with 'git log' which is not possible when there are only the
>>>> versioned .bb files.
>>> You can follow changes to the .inc but not anything that went in and
>>> out of the .bb, but I do concede that git not tracking the renames
>>> directly does mean some histories are harder to track (although simple
>>> to follow as the commit where the history stops will tell you where to
>>> pick it up again).
>>
>> git log --follow foo_1.2.bb handles 90% of this:
>
> it's not only 'git log'; it is 'git blame' too and because git does not
> support renaming of files natively, the 'git log --follow' method is
> error prone and might compare the wrong files resp. fail completely when
> there are too much changes.
>
Did you ever use 'git blame' for few lines most recipes have?

Andreas

Re: [oe] Style issue for recipes

[Enrico Scholz]

Andreas Müller <schnitzeltony-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
writes:

>> it's not only 'git log'; it is 'git blame' too and because git does not
>> support renaming of files natively, the 'git log --follow' method is
>> error prone and might compare the wrong files resp. fail completely when
>> there are too much changes.
>>
> Did you ever use 'git blame' for few lines most recipes have?

In other projects (e.g. linux kernel) I am using C-x v g in emacs very
often to see when/why a certain line was added.  In some OE recipes I
would like to do the same...


Enrico

Re: [oe] Style issue for recipes

[Burton, Ross]

On 4 September 2014 19:36, Enrico Scholz
<enrico.scholz@sigma-chemnitz.de> wrote:
>> Did you ever use 'git blame' for few lines most recipes have?
>
> In other projects (e.g. linux kernel) I am using C-x v g in emacs very
> often to see when/why a certain line was added.  In some OE recipes I
> would like to do the same...

Personally I find git blame totally disappointing in general, and
would love to see a "history browser" UI that let me see the history
of a line in a file without having to repeatedly git blame, get hash,
show hash, realise that change was whitespace, git blame hash^, rinse,
repeat.

If someone knows a good UI for blame-digging then please let me know!

Ross

Re: [oe] Style issue for recipes

[Trevor Woerner]

On 09/04/14 15:12, Burton, Ross wrote:
> If someone knows a good UI for blame-digging then please let me know!

http://vimcasts.org/episodes/fugitive-vim-exploring-the-history-of-a-git-repository/
http://vimcasts.org/episodes/fugitive-vim-browsing-the-git-object-database/

Re: Style issue for recipes

[Burton, Ross]

On 4 September 2014 15:12, Burton, Ross <ross.burton@intel.com> wrote:
> Quick question of style for the community to bikeshed on:  in the
> general case should recipes be split into foo_1.2.bb and foo.inc, or
> should they only split to bb/inc if there are multiple versions and
> generally there should just be foo_1.2.bb.

Another argument against widespread inc files: they encourage the
impression that maintaining multiple versions is just a matter of
having a .inc file.  The moment you start having to put
version-specific statements into a .bb you've entered a world of pain
in keeping the .bb files in sync, moving options into the .inc as they
become used by all versions, and purging old version-specific
statements.

Ross

Re: [oe] Style issue for recipes

[Paul Eggleton]

On Thursday 04 September 2014 15:12:02 Burton, Ross wrote:
> Quick question of style for the community to bikeshed on:  in the
> general case should recipes be split into foo_1.2.bb and foo.inc, or
> should they only split to bb/inc if there are multiple versions and
> generally there should just be foo_1.2.bb.
> 
> Specifically I'm looking at the libunwind patch for oe-core (moving
> from meta-oe) which adds libunwind_1.1.bb and libunwind.inc.
> Personally I feel that splitting them up complicates packaging and
> should only be done if there's actually multiple versions being used.

I think the conclusion we've come to is let's not have inc files just for the 
sake of having them; if we need to add them to share common functionality we 
will, but as time goes on it may be appropriate to factor some of them out. 
(Having said that I think it would cause more harm than good to go on a huge 
spree and merge a load of them away, at least at this point.)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre