Updating devel/tbb - Introducing devel/onetbb

Sat Jan 9 17:59:52 UTC 2021

On Saturday, January 9, 2021 9:49:24 AM CET Shane Ambler wrote:

Hello Shane,

Thanks for your reply.

> > - leave devel/tbb in place and introduce a new port: devel/onetbb
> 
> While I would generally support moving the old libs to a new portname,
> the fact that the project has renamed itself makes this acceptable.

Yes, this is the idea.

> The expected result is to have onetbb as the only option in the future,
> you should leave the new port to use a standard install and only if
> there is a need for it, alter the old port to co-install, you could get
> lucky and not have anyone that wants both versions installed.

I first thought about that too, but once several ports have started to use 
devel/onetbb, we could be in a situation where we have to relocate devel/tbb 
in a hurry (to avoid the CONFLICTS) because important ports still depending on 
devel/tbb cannot install anymore. I would like to avoid breaking important 
dependent ports that way as it can be anticipated.

I don't know each failing port, but for example I have the following deps on 
my desktop machine (default options) :

tbb <- suitesparse <- eigen <- movit <- mlt <- kdenlive <- kdemultimedia

so anyone wanting to install a port using the new devel/onetbb will be unable 
to install kdemultimedia and that's a no-go for me. What I mean here is that 
just leaving devel/tbb and devel/onetbb in place and hoping noone will be 
facing a CONFLICT seems unrealistic.

So that leaves only two possibilities :

1) Move devel/tbb to a dedicated subdir and install devel/onetbb to its 
default location. Here, we just anticipate what is written above. As you say, 
as having devel/onetbb-only is the target, that would be the best solution 
*BUT* it has the major disadvantage of having to patch all the current 
dependent ports. This is error-prone and will require extra work I won't have 
time to do. As I already wrote, I would prefer each porter to patch each port 
himself (because he is the one who knows his port better that anyone). That's 
why I suggested the second option.

2) The second option is to do quite the opposite : as everything is working 
fine now, don't touch anything and just introduce devel/onetbb in a way that 
it does not CONFLICT with current devel/tbb (i.e. in a dedicated subdir). It 
has several benefits : first, we don't break anything, then we leave each 
porter time to move their ports to devel/onetbb (we will not have to do that 
in a hurry) and finally, as each porter will have to move each port, if it is 
done by using a facility such as pkgconf, we gain a certain flexibility we 
don't have right now and that will ease next move (if there is one). The only 
disadvantage is that the library will not be located in the default paths 
anymore, but in a subdir. As we will have to patch dependent ports anyway to 
make them either detect the relocated devel/tbb (1st solution) or the new 
devel/onetbb (2nd solution), is that a problem ? Several ports already do that 
to be able to install several versions at the same time.

That's why I still think it would be easier and less error-prone to introduce 
devel/onetbb to a specific location and go for solution 2).

I would be pleased to receive other feedbacks. Maybe I am missing something 
here... ?

> Use bugs.freebsd to manage the update, start with submitting onetbb, and
> add conflicts with tbb. If dependent ports don't update and people want
> both installed, submit changes to allow tbb to co-install and have
> depends on bugs for each port that breaks so they get updated when the
> tbb changes get committed.

If we choose the second option, bugs.freebsd.org will probably be of less 
need, but it may be interesting to open a PR to follow ports migration anyway. 
I'll keep the idea in mind, thanks.

> The blender port uses seven of the other ports (with options on), with
> three others being slaves of one, so I expect that means a third of the
> ports will need to be updated together, as I doubt they will work
> together if they link to different tbb libs.
> 
> > - add a PKGNAMESUFFIX to devel/tbb to 'freeze' its version and modify
> > description to indicate the 'legacy' status of the port
> 
> I don't see a need to make these changes to the existing port. Maybe
> adding a note in the pkg-descr could make people aware of the new port.

Yes, I will do that too.

> > - [let maintainers migrate their ports to that new version]
> > - at some time (?), mark devel/tbb as DEPRECATED with an EXPIRATION_DATE
> > and do the same for remaining (non-updated) deps
> 
> As long as the existing tbb library compiles, it can stay as it is. Once
> maintaining the old port to build with new compilers/systems becomes a
> chore, then mark tbb and deps as deprecated and give them six months to
> update or be deleted. If all the deps get updated before then, the old
> tbb port can just be deleted.
> 
> If a port or two wants to stay with the old tbb, then let them maintain
> the tbb port.

Yes, why not. We can imagine keeping the old devel/tbb for a certain time if 
it still builds.

Thanks again for your feedback!

Best regards,

-- 
Ganael LAPLANCHE <ganael.laplanche at martymac.org>
http://www.martymac.org | http://contribs.martymac.org
FreeBSD: martymac <martymac at FreeBSD.org>, http://www.FreeBSD.org