(virtualbox) Split out extension pack into separate package

[pauby]

Discussed in #1961

^{Originally posted by TheCakeIsNaOH July 30, 2022}
The virtualbox package currently has an option (via a package parameter) for installing the extension pack. This is not following the best practices for packages, since package on the Community Repository are supposed to install only one piece of software at a time.

Currently, it looks like the checksum for the extension pack is incorrect, which is causing issues, because the only option is to use --ignore-checksums, as the --checksum would get applied to both virtualbox itself and the extension pack. It also caused issues for a user on discord that had to deal with virtualbox not liking being re-installed on top of a preexisting installation of the same version, while trying to get the extension pack installed.

Therefore, I propose that the extension pack should be split off into it's own package.

[pauby]

There is a virtualbox.extension package that was deprecated in favour of virtualbox. Rather than picking this up and using it, we should create a new package with a name that doesn't include a .. virtualbox-extension-pack? Or virtualbox-extension?

[BobSammers]

I remember when these packages were separate before and I remember a lot of upgrade issues resulting. I recall they were merged specifically because of all the issues having them separate was causing.

Until recently (as noted elsewhere, "upgrade all" currently results in an error), this package has behaved much better than the previous two-package situation.

Are you confident that splitting them again is safe and the right answer to the current problem?

[pauby]

I recall they were merged specifically because of all the issues having them separate was causing.

Can you elaborate on what sort of issues there were?

Are you confident that splitting them again is safe and the right answer to the current problem?

If you have to upgrade one application, rather than the other, then we need a new version. What version does the package follow in that case? And installing the same version of VirtualBox is causing people problems, as does the version 'mismatching'.

We should only ever have one software application in a package. Including two here isn't normal.

[BobSammers]

I knew you'd ask this :) . I looked back at the Disqus discussion earlier for the VirtualBox package to see if I could get something more concrete but I didn't get anywhere.

I think the problem may have been that the two packages got out of sync sometimes due to verification delays. As they are very closely tied, that would result in deployment errors.

[BobSammers]

Actually, there are some comments on the deprecated extension pack page you linked to above (for example one near the top by Michael Ray, can't see a way to link directly, sorry) explaining that the deprecation was taking place to, "prevent the version discrepancies going forward".

This type of problem (version discrepancy) is certainly what I remember happening and it wasn't an isolated incident.

[pauby]

Problems back then and problems now, balance each other out, I feel. We can only, in my opinion look to something else in the 'pros and cons' list to determine what we should do.

From a strictly package perspective, it's clear we should separate them (for the reasons I mentioned above). But it would be naive to stop there. We're all open to opinions on this, but the repository team are leaning towards separating them out so good arguments in favour of the status quo are welcome.

[BobSammers]

Problems back then and problems now, balance each other out,

Only if they're equal in magnitude. I don't have data, unfortunately, but my impression is that common problems in the past have been almost entirely eradicated - this current issue is a blip.

good arguments in favour of the status quo are welcome

Given the history, I was surprised to see this thread, but I don't think I have the knowledge to take part in a detailed discussion about the relative merits of different packaging ideologies or the history of this package specifically. I can only apologise if my comments aren't helping!

My intention was just to flag up the fact that there was a reason work was done to put these packages together, having previously been separate. I hope any potential pitfalls will be considered before work is done again to reverse the previous change.

I believe the problem was that the two packages are very version sensitive in the way they operate together. If Chocolatey and / or the repo maintenance system can now guarantee that the two packages will be updated and moderated in sync (which was apparently difficult previously), this is likely to be a beneficial change for the reasons you have mentioned; if not, my concern is that this change could cause more problems than it solves!

[pauby]

Only if they're equal in magnitude.

Agreed. But we don't have enough information on the problems before to suggest they are. We need to go on what we know now - what you've reported and what we see as issues in this repository.

this current issue is a blip.

This current issue can't be solved because packaging two pieces of software in the same package causes problems that can't be solved unless we break them out. These are fundamental problems.

If Chocolatey and / or the repo maintenance system can now guarantee that the two packages will be updated and moderated in sync (which was apparently difficult previously

We cannot guarantee that. Packages go in and 99% of the time they come out of the error end as expected. But this is a community repository and we have no SLA's, guarantees or promises with it.

my concern is that this change could cause more problems than it solves!

Mine too.

[pauby]

Given this discussion comment, it feels like a case of damned if we do or damned if we don't.

I think we have three options:

1. Keep the existing state of affairs of one package.
2. Split, as proposed, into two packages (VirtualBox and VirtualBox Extension).
3. Request a new maintainer pick this package up.

For 1 and 2, we would need to update the package description to say why the packages are one / separate to try to head off anybody who has an issue with the consequences of having them as one / two packages. In general, people don't read these, so the impact will be minimal.

I suggested 3 as we are going to get issues raised whether we split it or not, and I don't feel this is something we want to spend time on. A maintainer, with a few packages, has more time to dedicate to it. The community team here has 352 packages to maintain.