Package Descriptions

jdillard

2.3 seems to have the vague description, unless I am misunderstanding.

KOM

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.

doktornotor

@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.

jimp

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.

doktornotor

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>

jimp

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

KOM

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.

doktornotor

@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.

::) ::) ::)

jimp

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.

jimp

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)

KOM

As a user I just want to know what I'm installing, and internal version numbers aren't helpful.

jimp

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.diff

Granted it only shows one level, but it gets the point across. Formatting could be better.

jimp

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.

KOM

You're awesome.

Have a free kiss from Mahir!

mahir.jpg_thumb