A position on solving issues with Virtualmin packaging

Virtualmin
1

I would like to state my position on a practical way forward to issues raised in thread I got Virtualmin working on ARM64 (Ampere). If you read the post below in full, you might feel my position is obvious.

To make it simpler, I will refer only to packaging for Debian.

I also want to make it clear I am referring only to packaging, not to the quality of code or to the overall design of Virtualmin, which I believe is very high.

The basis for my points below is that Virtualmin is built with non architecture specific code and so, if properly packaged, should EASILY run on all architectures supported by Debian, using packages also supported by Debian on such architectures. The maintenance of such packaging of Virtualmin should also be very easy, as one code base would be fit for all architectures.

  1. I believe Virtualmin has made a mess of packaging for Debian and they are doing far more work than is necessary to support Debian. If you want strong evidence than look through the contents of thread at I got Virtualmin working on ARM64 (Ampere), the hostility to issues raised, the continual lack of clarity and the failure to adequately answer questions. I could also provide other specific evidence. Also look at the complaints in the forum from Virtualmin about not wanting to support other architectures due to the amount of packaging work required. This does make sense.
  2. I believe a proper fix of packaging for Debian would enable installs and updates of packaging to work properly and lower the burden of Virtualmin maintenance massively.
  3. I believe Virtualmin at least owes it to Debian to ensure Debian can be installed and updated on architectures other than x86, for packages for which Debian itself supports
  4. If a binary package used within Virtualmin is not supported on an architecture by Debian than Virtualmin cannot be expected to install and update such package on that architecture. In fact it gives Virtualmin an easy way out of supporting use of such packages.
  5. This is not contrary to a policy by Virtualmin of ‘only x86 support’.
  6. Anyone who needs support to run on non x86 architectures would need to organise this themselves or externally from others.
  7. The support policy could be altered to ‘no support for Virtualmin features on architectures not supported by matching feature by Debian on that architecture’.
  8. Packaging is too complex for any small organisation with very limited resources to ‘self-certify’ their packaging for a distribution, which is what Virtualmin is in effect doing.
  9. I believe Virtualmin should swallow their pride, approach Debian or known community experts in Debian packaging and ask for a review
  10. Until a review by an accepted independent expert in Debian packaging has been published and acted upon, we must not accept that Virtualmin is appropriately packaged for use with Debian on x86 or any other architecture
  11. I believe the conclusion of a review would be the most practical solution would be to submit all packaging of Webmin, Usermin and Virtualmin gpl for distribution by Debian, where they can receive expert guidance for free.
  12. The above would, in effect, be a continual form of certification of Virtualmin for that distribution, that would likely greatly increase the appeal of Virtualmin, including to the pro version which Debian would of course refuse to package.
  13. Any packaging for a distribution, such as Debian, not installable by the distribution itself should never be accepted as trustworthy
  14. To get over the problem of availability of most recent updates, Virtualmin can offer the choice to use more up to date repositories, as long as their packaging is consistent with regular Debian repositories

We should at least have a choice. Since Virtualmin offers an interface layer over an OS then we should have the choice to install through the OS instead of independently of the OS. Otherwise Virtualmin cannot be considered to be credible in its claim to be an interface layer over the OS.

I don’t know what the specific issue was with Webmin getting removed from Debian was before. Since Virtualmin requires Webmin, this information should be available to us, as it basically is a message that Webmin is not good enough for Debian. This is a big concern. It is possible Debian was unhappy about Webmin claiming to be a skin over Debian basic OS features, instead of more accurately and appropriately claiming to be a skin over basic supported features of Debian on a particular architecture and not hiding features it could easily test were not available for use on a particular architecture (by reading packaging meta information for that architecture).

The same principle applies to Virtualmin, a module of Webmin. If Webmin is rejected as unfit for Debian then so also is Virtualmin.

If Webmin, Usermin and Virtualmin gpl is accepted by Debian for packaging, then this would provide a massive credibility boost for Virtualmin that could transform into massive sales boosts. It would also give confidence that Virtualmin are team players and can take being told what to do, when it is appropriate.

Virualmin dabbled in paid ticket support but stopped. They have also mentioned about the massive fees they could charge if they provided enterprise level support. Such customers expect accepted standards.

2

I would need to see an exact error, if our architecture-independent packages fail to install on any architecture that have the necessary dependencies (including ARM). It works for me. It works for others.

I am doing literally nothing to stop you from running Virtualmin on ARM; all of our Webmin and Virtualmin packages are architecture independent, and the repos include the all or noarch architecture. It installs and updates quite easily, but it is missing the mail stack (because of a missing binary package). We have documented which distros and architectures are fully supported (including the mail stack).

Until you show me an exact error indicating a problem with our architecture independent packages and repos when installing or upgrading on ARM, I can do nothing. It works for me. As I’ve said.

I’m being dismissive at this point because you keep saying things about our packages that simply aren’t true, and are demonstrably untrue. I don’t know how to satisfy you when what you want is already there.

We can’t make Debian maintainers start shipping Webmin/Virtualmin packages, or review them. I don’t know how you’d get the idea that we could. They aren’t on our payroll (and we don’t have money to pay people for that). We have never discouraged others packaging our software and we don’t do anything to prevent it (many distros and OSes have shipped or continue to ship Webmin and Virtualmin packages), though the old Debian packages were awful and unmaintainable (which is why nobody, including us, wanted to keep maintaining them and why they were removed due to lack of maintenance). And, our packaging tools are open source. If you believe there is a problem with our Debian packages, we welcome PRs against the Webmin repo to the file makemoduledeb.pl (and makedebian.pl for Webmin itself) to fix it. It’s not about fucking pride. That’s ridiculous. It’s about nobody else doing the work. We do the work. If you think we do the work wrong, you’re welcome to make PRs.

Honestly, I don’t know how to continue a conversation about complaints that aren’t based in reality. You can, and have, installed our packages on ARM. Others have, too.

And, we have never said we won’t support ARM. We’ve always said, “We don’t have time right now.” You’re taking an awful lot of my time away from useful stuff right now.

1 Like
3

OK, so in your mind I have nothing valid to say and am wasting your time. I guess I will leave it at that.

4

you’ve talked the talk now walk the walk post the errors you are getting

5

This topic has nothing specifically to do with the errors I mentioned. Fixing any such errors, when they reoccur, will not solve any of the packaging issues very clearly mentioned.

6

I’m sorry we got off on the wrong foot on all this. I responded to your initial complaint with hostility because it felt like an unfounded accusation, and I should have been more diplomatic. But things have really gone off the rails here.

I, honestly, don’t know what to do with your complaints.

You’ve said there are problems with our packages, but you won’t identify what those problems are. If you show me an error, I can fix it. I am unaware of any problems installing our architecture-independent packages on any system that meets the dependencies.

And, you’ve said the only way to solve the problems with our packages, problems you won’t identify, is to demand volunteers on an unrelated project take over maintenance of those packages. I don’t know how to make other volunteers do things they have expressed no interest in doing. We aren’t stopping Debian volunteers from packaging our software. We never have.

If our packages have technical problems, please identify the problems and provide the exact error message(s) you get. I will fix them. I am unaware of any issues with our packages. They install and work everywhere I have tested them, including ARM, though testing on ARM has been extremely light, as we haven’t had time to devote to making it a supported architecture yet
but we know it installs and we know there are a handful of folks running Virtualmin on ARM, and they aren’t reporting problems with the packages.

I won’t be dropping everything I’m doing to become a Debian developer. That’s not where my interests lie. I’m a volunteer, too, I haven’t been paid for Virtualmin work in years. If you want Webmin and Virtualmin packages in Debian, I encourage you to begin that work or employ someone to do that work. The vast majority of our software is Open Source, there is nothing stopping you from working on getting it into Debian. But don’t demand other people do it for you. If that’s what you want, then put your effort into doing that. It’s not a goal or interest of mine.

7

@Joe There are no ‘demands’ anywhere. Please do not confuse outcome with method. You are complaining about being unpaid yet you are making no practical changes, including about attracting sponsorship.

Outcomes

Here are two outcomes of potentially adopting Debian packaging.

  1. In the long term, a reduction of the administrative burden of maintaining packaging for Virtualmin for Debian and derivatives, with an equivalent model for Virtualmin Pro as well as recent updates

  2. A paradox of making Virtualmin more popular commercially through inspiring confidence by having officially approved Debian packaging.

Methods

  1. Go it alone and just start official Debian packages by declaring Virtualmin themselves to be voluntary maintainers from the start. The experience for Virtualmin would be brutal and highly embarrassing. The amount of initial work would be tremendous, including the amount of work that would need to thrown out with restarts.

  2. Make an appeal for a Debian expert to write a report or review voluntarily. A proper report would include options, including paid options, such as an option to have experienced paid assistance and an option to develop packaging in private before public submission

  3. Just straight up contract a Debian expert to get over the initial hump. First contract to write a report as above.

Sponsorship

Let potential sponsors engage in a meaningful way. @vander.host is looking for a way to sponsor for a year. I saw no public thanks to @vander.host for their offer from Virtualmin. I thanked them. Also @vander.host followed up with a complaint. I guess they were highly frustrated. For a potential sponsor, all of the points I have made are highly relevant.

If Virtualmin wants to attract and keep sponsorship they need to work at it. Sponsors need to feel welcome and to be included in decision making within agreed parameters. Sponsors need to be kept informed with comprehensive reports and sponsors need to have an ‘open line’.

8

Perhaps more of a US of A think but remember, “Ask not what your country can do for you. Ask what you can do for your country.” An open source project is like that. Everyone doing what they can to make it better.

Any ask of the staff right now discounts all that they do already. I’m not saying a critique is useless but, in the end, it is up to those doing the work to make the decisions.

I was elected president for a club that had long contentious meetings. Most centered around things people thought we should be doing. So, I made a rule. You suggest a project, YOUR name is going to be at the top of the work list for that project. Result. 10 and 15 minute meetings.

9
  1. Virtualmin packaging can be simplified. So can Webmin packaging
  2. Frightening messages about ‘unsupported architectures’ can be eliminated, as for ARM64 with Debian.
  3. With simplification of packaging, Debian is likely to be more re-accepting of Webmin and accepting of Virtualmin gpl.
10

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.