Upgrading [deprecated] samba413 to samba416?

macer

macer

When upgrading (using latest) I received a message from pkg saying that samba413 is now deprecated and will be discontinued at the end of the year. The fbsd server is a NAS and joined to an AD. I just don't know how to go about moving from 413 to 416. Do I remove 413 then install 416? Do I install 416 over 413 (this doesn't sound like the right way to do it)? Or is there something I'm missing here? Any information on this would be appreciated.
 
macer said:
Do I remove 413 then install 416?
Click to expand...
Yes.
macer said:
Do I install 416 over 413 (this doesn't sound like the right way to do it)?
Click to expand...
Should work too, it'll complain about a conflict and remove 413 before installing 416.

Check if you have anything depending on 413 specifically though. Removing 413 would remove those too. So far I've only updated 'standalone' server configurations, those were really simple. Not entire sure how things work with AD. Is this server connected to an existing Microsoft AD? Or are you running Samba as a domain controller?
 
I thought so too. pkg did not give an error about samba413 being installed but I stopped at the y/N part. Thank you for the response. I will try remove 413, install 416, restart service approach and keep my fingers crossed.
 
macer said:
pkg did not give an error about samba413 being installed but I stopped at the y/N part.
Click to expand...
It will complain when you enter 'Y' and it actually tries to install it.

macer said:
restart service approach and keep my fingers crossed.
Click to expand...
I recommend stopping the service before removal/install. Sometimes with a newer version of a service it'll refuse or fail to stop the old one. Stopping it before replacing is the best way.
 
zirias@ said:
Problem still exists here:

bsd.default-versions.mk « Mk - ports - FreeBSD ports tree

cgit.freebsd.org cgit.freebsd.org

This means any package depending on samba will pull in samba413, unless you build yourself with DEFAULT_VERSIONS+= samba=416.

This issue is also mentioned in PR 270383 tracking addition of a newer samba port....
Click to expand...
Oh. I didn't even take that into consideration. I was just more concerned about a broken AD once I replaced samba413. I guess there isn't a sane way to upgrade samba from samba413 to 416 with pkg now then if someone has a lot of samba dependent applications? I guess this will be a bigger issue on Jan 1 when the pkg / port will be removed. I'll take a stab at it over the weekend and see what happens during the upgrade and hopefully it doesn't consume an entire weekend trying to fix. :)
 
zirias@ said:
Problem still exists here:

bsd.default-versions.mk « Mk - ports - FreeBSD ports tree

cgit.freebsd.org cgit.freebsd.org
Click to expand...
Generally, as multiple stated valid options in:
Code: 
# Possible values: 4.13, 4.16
SAMBA_DEFAULT?=		4.13
Is there a mandatory rule, guideline, general consensus, vague commonality or otherwise understanding in the ports community about the difference between Possible values ? Obviously, only one can be elected as the actual default value.
What is the strongest statement you can reliably make?
 
Erichans said:
Is there a mandatory rule, guideline, general consensus, vague commonality in the ports community about the difference between Possible values ?
Click to expand...
Not sure I understand the question? But the primary reason has to be an actual port existing. As there is a net/samba413 and a net/samba416 port, those are the only possible values it could have. If a samba419 port gets created, then the possible values will include 4.19. But that version hasn't been ported yet.
 
macer said:
I guess this will be a bigger issue on Jan 1 when the pkg / port will be removed.
Click to expand...
When the port is removed, the default for DEFAULT_VERSIONS must be updated, otherwise ports would be broken. So, this will be no issue at all ... but it really might make sense to change the default value before the old port is removed...

Erichans sorry, I'm not sure what you're asking, could you explain a bit more please?
 
I understand that depending on a certain existing situation (especially when considering an upgrade with dependencies involved) the user could have a preference for one "valid option" over other ones; that's not what I'm trying to address with my question.

When one is free to choose, for example a complete new installation with no additional contraints, are all the options mentioned equally valid, (well) tested; is the elected one a choice of perhaps conveniance (it's clear to me that minimal constraints have to be met, such as a port has to exist). What rules or guidelines have been followed to elect one over all the other possible values to be the actual default? Are all valid options mentioned for example equally tested?
 
Erichans, it's mostly a "use your best judgement" kind of thing ... often the maintainer of the ports/area affected by the setting decides which one is the fallback default, and sure, that one will be the "best tested" one (e.g. because official packages will use it). Nevertheless, every selectable option should work (and if there is a problem with one, opening a PR about it is suitable and desired). Some of these (like e.g. the default llvm version) are more "delicate" than others, they certainly won't be changed without at last an exp-run, etc ...

My recommendation would be, don't set anything in DEFAULT_VERSIONS "just because" or to "play around", but do set something if you have an actual reason in mind. Also, if you think the default for one of the options should be changed, open a PR and give your reasoning ;)
 
Tried setting samba=4.16 some time ago and ran into several issues. It was primarily an issue with several filemanagers from desktop environments (some of them have support for SMB shares). Probably tried it at a too early stage though (4.16 was quite new back then), should really try again some time soon.
 
It would be nice if pkg had a means to upgrade the deprecated packages. Maybe that would be a more straight forward solution for Joe Users like myself. In the case of deprecated samba413, would it just say 'this is deprecated' and suggest samba416 or would it still be up to the user to stop, remove, install, start samba? There aren't too many packages that use this separated branch methodology. The only one that usually affects users would be something like python (which is the only one that comes to mind off the top of my head).
 
macer said:
The only one that usually affects users would be something like python (which is the only one that comes to mind off the top of my head).
Click to expand...
Python, Ruby, Perl, PHP, Java and a whole bunch more actually. Just take a look at /usr/ports/Mk/bsd.default-versions.mk. Any of those could have their 'default' version changed. This is almost always due to an older version being deprecated upstream. Changing the 'default' version willy-nilly can be quite tricky as this change could potentially cascade down to hundreds of dependent ports getting hit. And more often than not, some of those dependent ports refuse to build or work correctly after such a change.
 
macer said:
It would be nice if pkg had a means to upgrade the deprecated packages.
Click to expand...
Yes, it would. Well, actually it is (just install the newer one, it will conflict with the older one and pkg will attempt to remove it to solve this), but as soon as dependencies are involved, that can be a roadblock ... you can't just change the dependencies of a package.

A partial solution could be a feature some other packaging tools offer: A mechanism called e.g. "provides" in Debian. Taking the example of samba, this would mean there's a "virtual" package called samba, packages needing samba would just depend on that virtual package, and both samba413 and samba416 would have a property Provides: samba, telling the package manager this can fulfill a dependency to samba. Might be a wishlist item for pkg.

But: This would not help when the dependency is about shared libraries and the ABI version of a required library isn't the same. E.g. if some binary wants to link a libfoo.42, it's impossible to just use a libfoo.43 instead without recompiling. So in a nutshell, there will always be situations requiring you to build your own packages if you want different dependencies than the official packages, there's just no way to completely avoid that...
 
In getting back to the original question and with relation to zirias' answer...

# service samba_server stop
# pkg install samba416
--- pkg detects samba413 and asks to remove / replace y/N: Y
# service samba_server start

profit.

I need to check things out a bit more to make sure it's all functional but it seems to work. I guess in my case (using samba strictly as a fileserver) it works out. I hope the other discussion about pkg dependencies really gets addressed though. Maybe it might be time to take a better look at this to find a more streamlined way to upgrade packages or prevent version splits in the repository where you may bump into an eol deprecated pkg?

Thank you all for your input.
 
I'm seeing this with packages as well. I've been waiting for a very long time to update samba413 to, really, anything not EOL. However, the dependencies simply won't have it. Looks like packages such as gvfs, thunar, and other xfce4 related packages still depend on 4.13. Until they're updated to depend on a newer, non-EOL version, we're stuck. I'm certainly not being pushy or bad-mouthing any maintainers or anything like that, but a full year and nine months since EOL seems just a bit excessive to get that updated. I certainly hope this is resolved soon.
 
ek said:
Looks like packages such as gvfs, thunar, and other xfce4 related packages still depend on 4.13.
Click to expand...
Yes, DEFAULT_VERSIONS is still set to 4.13. If you build your own repository you can set this to 4.16 and have everything depend on that.
 
You must log in or register to reply here.
Back
Top