Page MenuHomeFreeBSD

finance/gnucash flavoring
ClosedPublic

Authored by madpilot on Dec 13 2017, 3:49 PM.
Tags
Referenced Files
Unknown Object (File)
Feb 12 2024, 2:52 PM
Unknown Object (File)
Feb 12 2024, 2:52 PM
Unknown Object (File)
Feb 12 2024, 2:52 PM
Unknown Object (File)
Feb 12 2024, 2:52 PM
Unknown Object (File)
Feb 12 2024, 2:52 PM
Unknown Object (File)
Feb 12 2024, 4:48 AM
Unknown Object (File)
Jan 12 2024, 4:16 PM
Unknown Object (File)
Jan 7 2024, 5:18 PM
Subscribers

Details

Summary

The gnucash port at present has a single option to choose on which guile version to depend, which defaults to guile1.

Changing the option's default has proven problematic, due to guile1 and guile2 conflicting with each other.

At the same time guile1 is old and unsupported upstream, and the gnucash developers have stated they intend to drop guile1 support in the next major release.

Converting those options to flavors allows us to distribute both versions so also binary package users have an option. This also allows to change the default to guile2 since users can change flavor, if desired.

I've also added an UPDATING note to let the users know about this.

Diff Detail

Repository
rP FreeBSD ports repository
Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 13573
Build 13797: arc lint + arc unit

Event Timeline

Is there any interest in having both versions ? Do they do things differently ? Wouldn't simply changing the default to use Guile 2 be simpler ?

In D13478#281891, @mat wrote:

Is there any interest in having both versions ? Do they do things differently ? Wouldn't simply changing the default to use Guile 2 be simpler ?

The resulting packages are equivalent regarding functionality.

The port shortly switched to strictly using guile2 between r369578 and r370067. At the time I got many complaints about pkg forcing users to disinstall many other packages depending on guile1 to satisfy the guile2 requirement.

I thought I could take advantage of flavors to have both packages available, so users insisting on guile1 had an easy and fast solution without need for recompilation.

At the same time I see the list of ports depending on guile1 has considerably shrunk lately, so it is possible the backlash would be quite smaller now.

I'd anyway would like to have the flavor available to avoid any backlash.

In D13478#281891, @mat wrote:

Is there any interest in having both versions ? Do they do things differently ? Wouldn't simply changing the default to use Guile 2 be simpler ?

The resulting packages are equivalent regarding functionality.

The port shortly switched to strictly using guile2 between r369578 and r370067. At the time I got many complaints about pkg forcing users to disinstall many other packages depending on guile1 to satisfy the guile2 requirement.

I thought I could take advantage of flavors to have both packages available, so users insisting on guile1 had an easy and fast solution without need for recompilation.

At the same time I see the list of ports depending on guile1 has considerably shrunk lately, so it is possible the backlash would be quite smaller now.

I'd anyway would like to have the flavor available to avoid any backlash.

Mmmm, ok, I get it. (It looks stupid that lang/guile and lang/guile2 are conflicting though.)

As a side note, could you use devel/arcanist, or at least generate a diff with full context like it does, with svn diff -x -U9999 or git diff -U9999.

finance/gnucash/Makefile
102

This could be .else.

Also, as the default flavor is implicit and may not be set, if you want this to work, you'll have to write something like:

.elif ${FLAVOR:Uguile2} == guile2

or

.elif ${FLAVOR:U${FLAVORS:[1]}} == guile2
madpilot edited the summary of this revision. (Show Details)

Fixed the elif stanza, simple .elsse seems more correct in this case.

Sorry, my first try at using arcanist did not work out as expected, and unrelated changes slipped in.

I'm fixing this shortly.

Fixed patch to only include related changes.

I was going to say that the flavors block should happen earlier, but in fact, it is all the options block that should happen later. See Chapter 15. Order of Variables in Port Makefiles. But this can wait for another time.

This revision was not accepted when it landed; it landed in state Needs Review.Dec 15 2017, 5:20 PM
This revision was automatically updated to reflect the committed changes.