Package Descriptions
-
Can someone explain to me the logic of using internal version numbers for packages, but not exposing the underlying software versions??? 2.1.x used to have both. 2.2.x has internal and a vague description. Now 2.3 has nothing but the internal version. How is removing all package metadata except an inscrutable internal number useful to anyone?
-
The package versions must change in order for the system to rebuild them, we cannot use the former style of having two numbers in there, it isn't compatible with the new package system. Using just the underlying version isn't good either since it would diverge as the package is edited.
The package maintainer is free to use the same one as the binary if they want, it just has to be one number and not two numbers.
It may be possible yet to have it display versions of dependencies, but that may not be possible in a timely manner.
-
2.3 seems to have the vague description, unless I am misunderstanding.
-
Thanks guys.
The vague description is there, but it would be better for that field to contain the base version of the software along with the general description. Otherwise it can get confusing. For example, squidGuard is at 1.9.x when the real package is at 1.5-4 or something. I guess it's up to the package maintainers. Maybe only accept PRs when they have an updated version if it has changed? I don't know.
-
@KOM:
Maybe only accept PRs when they have an updated version if it has changed? I don't know.
This is simply not possible. With the new packages, you MUST bump the package version, otherwise noone can get the updates. Also, not exactly a good idea to cause downgrades when the package version is higher than the underlying software version (if any). The 2.1.x versioning was a complete mess, somewhere after 2.2 it was sanitized in a way that the upstream versions got lost (I posted a complaint about this many many months ago…, and we got exactly nowhere with this in 2.3.
-
The best way would be to automate it in pkg and display a list of the package's dependencies in the GUI so you can see the versions of everything it pulls in. I am just not sure how viable that is at this stage.
-
I cannot even see how to get the dependency version now (the former <depends_on_package_pbi>tag). Where's this info now/what decides which version is used/how to make a newer version used?</depends_on_package_pbi>
-
It's recorded by pkg in the data it keeps.
: pkg info -d pfSense-pkg-openvpn-client-export-1.3.5 pfSense-pkg-openvpn-client-export-1.3.5: zip-3.0_1 p7zip-9.38.1_2 openvpn-client-export-2.3.8 -
Perhaps just an entry in the Description field like Based on squid 3.4.10 or something like that for the major component? A system that does what you describe sounds cool, but also a lot of work. A Description entry is much simpler, and only needs to be bumped when the maintainer compiles against a newer version of the component. Otherwise, package versions can be bumped with every edit/release while the Description version remains untouched if the base component stayed the same.
-
@KOM:
Perhaps just an entry in the Description field like Based on squid 3.4.10 or something like that for the major component?
Apparently it's no longer based on squid 3.4.10 - which makes the package broken in a multitude of places; notably the infamous SSL/MITM stuff. Which gets me back to my previous unanswered question: "Where's this info now/what decides which version is used". Things are not doable in this way. It surely is wonderful I can run
pkg info -d <some_package></some_package>and see what's going to be installed as a user. But if someone is supposed to maintain the packages, they MUST be able to stop such major release upgrades. It's not viable to end up with a minor cosmetic bugfix resulting in the dependency being rebuilt and accidentially bumped to a completely different upstream branch.
::) ::) ::)
-
That's up to the Makefile and what is in the ports tree, see the RUN_DEPENDS line in there, it lists what the requirements are. Squid 3.4 has been gone from the FreeBSD ports tree since April, so we have no way to build that. Normally they'd keep a squid34 port around for cases like this if 3.5 is known to break something or cause upgrade issues.
Worst case, we could commit our own squid34 port to build Squid 3.4 or try to get one into the ports tree upstream if it really can't be done with 3.5. If it comes to that, open a Redmine issue and we'll see what we can do.
-
And FYI- This situation was exactly the same on 2.2.x, 2.1.x, 2.0.x, and before – we can only build what is in the ports tree unless we commit our own copies of the ports (which is generally frowned upon)
-
As a user I just want to know what I'm installing, and internal version numbers aren't helpful.
-
What I'm saying is we already have access to the info, it's there in the metadata, we just don't display it. We only need to nudge the code to show it. It's not impossible, it just needed to be done the pkg way.
Give this a whirl, see what you think:
http://files.atx.pfsense.org/jimp/patches/show-pkg-dep.diffGranted it only shows one level, but it gets the point across. Formatting could be better.
-
I went ahead and committed a prettier version than my initial patch (though I also updated the patch). It will show up in snaps/gitsync shortly.
-
You're awesome.
Have a free kiss from Mahir!
