Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Hot mess of a package - who to talk to about removal?

Here you can discuss every aspect of Debian. Note: not for support requests!
Post Reply
Message
Author
User avatar
VA1DER
Posts: 14
Joined: 2018-12-20 04:34

Hot mess of a package - who to talk to about removal?

#1 Post by VA1DER »

There is a package, postfixadmin, which I just tried on my Debian 11 (testing) system. Within about 30 seconds I was about to file three different bug reports. All of them were previously filed, and a couple were two years old. These are all installation bugs which render the package, as shipped, unusable. The nature of one of them makes it dreadfully obvious that the maintainer clearly hasn't actually even used or tested his packages out in some time. Upstream changed the directory structure, requiring a writable temp folder, and also requiring a change to the folder you alias the web site to. It's actually impossible to use as shipped, and the maintainer has put out at least three releases with it like this. He can't possibly have even tried it.

One of the bugs I had actually reported back in 2015 and forgotten I did and worked around then.

This package is a bit of an embarrassment. Debianized packages of things like this, roundcube, wordpress, phpmyadmin, etc, are supposed to be value added onto upstream. This one is actually value detracted. IOOt's worse than installing it from scratch. Who do I speak to about getting it pulled from the upcoming Debian 11 release? I've never been clear on who the next level up from a package maintainer is.

kedaha
Posts: 3521
Joined: 2008-05-24 12:26
Has thanked: 33 times
Been thanked: 77 times

Re: Hot mess of a package - who to talk to about removal?

#2 Post by kedaha »

Hello.
OK, so you have tried postfixadmin on your Debian 11 (testing) system and report that it is affected by installation bugs which render the package as shipped, unusable so you suggest its removal; however, what would you suggest replacing it with?
Have you also been unable to use the Debian postfixadmin in current stable due to these bugs?
According to the old bug number #897683 submitted in May 2018, the maintainer took over the package even though he couldn't test the package thoroughly because, as he candidly said, he didn't have enough knowledge of postfix, in order to make sure that it stayed in Debian because the original maintainer had stated that he also had no time to work on it: tracker.debian.org/pkg/postfixadmin]tracker.debian.org/pkg/postfixadmin:
RFA: The maintainer is looking for someone adopt this package.
The current maintainer is looking for someone who can take over maintenance of this package. If you are interested in this package, please consider taking it over. Alternatively you may want to be co-maintainer in order to help the actual maintainer.

I see that postfixadmin 3.3.5-1 was migrated to testing in February 2021 and, interestingly, postfixadmin 3.3.7-1 was accepted into unstable only last month by the original maintainer, who, one hopes, now has time to resume maintenance of the package.
VA1DER wrote:This package is a bit of an embarrassment. Debianized packages of things like this, roundcube, wordpress, phpmyadmin, etc, are supposed to be value added onto upstream. This one is actually value detracted.
Whatever its defects, any testing package is, by definition, not a definitive version so to propose the removal of this package I think is inadvisable since there are now, as then, good reasons for making sure that it stays in Debian even if it needs further configuration or workarounds on the part of a systems administrator who wishes to use it in the upcoming stable version of Debian.
I think that postfixadmin is the ideal virtual mail hosting interface for Postfix and would encourage you not to give up on this package because, whatever the teething troubles, the benefits of using official packages outweigh those of using untested upstream or third-party packages which may be affected by other, perhaps even worse, bugs and security issues which cannot be reported to Debian.
You may be interested to take a look at my forum post viewtopic.php?f=20&t=138101 from 2018 on this subject.
DebianStable

Code: Select all

$ vrms

No non-free or contrib packages installed on debian!  rms would be proud.

User avatar
VA1DER
Posts: 14
Joined: 2018-12-20 04:34

Re: Hot mess of a package - who to talk to about removal?

#3 Post by VA1DER »

kedaha wrote:Whatever its defects, any testing package is, by definition, not a definitive version so to propose the removal of this package I think is inadvisable since there are now, as then, good reasons for making sure that it stays in Debian even if it needs further configuration or workarounds on the part of a systems administrator who wishes to use it in the upcoming stable version of Debian.
The testing package is, by definition, the package that is on track to become the next stable and should be in a freeze right now. A year and a half ago the postfixadmin package in testing being in this state was, perhaps, acceptable. On the eve of Debian 11's release it isn't. Incidentally I've also looked at the package in Buster and it has the same issues.
  • Configuration file uses "msql" vs "mysqli" database setting. The newer "mysqli" setting is for MySQL 4.1+. When was the last time MySQL < 4.1 was shipped in Debian? Debian 7? 8?
  • Directory to point web server to changed. This changed in v3.2 back in 2018. "- move public facing stuff into public/, this allows us to stop exposing templates_c/ etc. to the world (but also means you'll need to adjust your webserver config)"
  • Writable templates_c directory required. This changed somewhere in version 3, I can't even find the reference. Circa 2016.
kedaha wrote:I think that postfixadmin is the ideal virtual mail hosting interface for Postfix...
Concur.
kedaha wrote:...and would encourage you not to give up on this package because, whatever the teething troubles, the benefits of using official packages outweigh those of using untested upstream or third-party packages which may be affected by other, perhaps even worse, bugs and security issues which cannot be reported to Debian.
Do not concur. While I personally would do it right, others most likely aren't going to appropriately put templates_c into /var/lib/postfixadmin. To fix the bugs they are going to follow the path of least resistance and stick it in /usr/share/postfixadmin where the rest of the installation is. People in general are not going to properly debianize the way they fix installation bugs. Which means that if/when the fixes do come down the pipeline it will make upgrading later more difficult. As the package exists now it is worse than using raw upstream. At least when people use raw upstream postfixadmin they will stick it somewhere like /srv, where it wouldn't interfere with a future working postfixadmin package.

It's current quality and especially the fact that its maintainer, by his own admission, cannot properly test it makes unstable the only appropriate home for it. This is not personal, it's just a fact. As it stands now it is better to simply remove the package from Debian 11 until and unless the above issues are corrected. I would appreciate it, if you know the answer, if you could please let me know to whom I need to make the case for the package's removal from Debian 11. For those who want the Debian package, they can pull it in from unstable after 11 comes out. Or a case can be made be reintroduce it into (then) stable.

If you want proof of what I'm suggesting, search for literally any tutorial or howto on the internet for installing postfixadmin in Debian. Exactly none of them suggest to use the Debian package.

kedaha
Posts: 3521
Joined: 2008-05-24 12:26
Has thanked: 33 times
Been thanked: 77 times

Re: Hot mess of a package - who to talk to about removal?

#4 Post by kedaha »

VA1DER wrote: The testing package is, by definition, the package that is on track to become the next stable and should be in a freeze right now. A year and a half ago the postfixadmin package in testing being in this state was, perhaps, acceptable. On the eve of Debian 11's release it isn't. Incidentally I've also looked at the package in Buster and it has the same issues.
  • Configuration file uses "msql" vs "mysqli" database setting. The newer "mysqli" setting is for MySQL 4.1+. When was the last time MySQL < 4.1 was shipped in Debian? Debian 7? 8?
  • Directory to point web server to changed. This changed in v3.2 back in 2018. "- move public facing stuff into public/, this allows us to stop exposing templates_c/ etc. to the world (but also means you'll need to adjust your webserver config)"
  • Writable templates_c directory required. This changed somewhere in version 3, I can't even find the reference. Circa 2016.
I think that moving templates_c into public/ is a good idea since the file was owned by root and write access allowed for the web-server user, www-data, which might pose a security concern.
VA1DER wrote: [ ...]While I personally would do it right, others most likely aren't going to appropriately put templates_c into /var/lib/postfixadmin. To fix the bugs they are going to follow the path of least resistance and stick it in /usr/share/postfixadmin where the rest of the installation is. People in general are not going to properly debianize the way they fix installation bugs. Which means that if/when the fixes do come down the pipeline it will make upgrading later more difficult.
That's right. Installation of the Debian postfixadmin package in Buster also involved further configuration, which for a skilled systems administrator is a trivial affair but nevertheless might be quite a bug for people in general.
VA1DER wrote:As the package exists now it is worse than using raw upstream. At least when people use raw upstream postfixadmin they will stick it somewhere like /srv, where it wouldn't interfere with a future working postfixadmin package.
Yes, the ideal would permit glitch-free seamless upgrades.
VA1DER wrote:It's current quality and especially the fact that its maintainer, by his own admission, cannot properly test it makes unstable the only appropriate home for it.
Well, the maintainer did say that he could not properly test it several years ago; one hopes that by now that things have changed.
VA1DER wrote:As it stands now it is better to simply remove the package from Debian 11 until and unless the above issues are corrected. I would appreciate it, if you know the answer, if you could please let me know to whom I need to make the case for the package's removal from Debian 11. For those who want the Debian package, they can pull it in from unstable after 11 comes out. Or a case can be made be reintroduce it into (then) stable.
No idea how a user might propose the removal of a package. Perhaps the first step would be via the bug reporting system.
VA1DER wrote: If you want proof of what I'm suggesting, search for literally any tutorial or howto on the internet for installing postfixadmin in Debian. Exactly none of them suggest to use the Debian package.
True, but this defeats the rationale of using stable Debian packages as opposed to upstream versions. Apart from submitting bug reports, which, if left unfixed, the only other constructive thing to do, assuming postfixadmin is not removed from Bullseye, would be to write an Installation Guide for the Debian Wiki, where these and perhaps other issues might be addressed, like, for example, making passwords set or updated in roundcube work well with postfixadmin, which I was able to solve in Buster after quite a lot of trial and error.
DebianStable

Code: Select all

$ vrms

No non-free or contrib packages installed on debian!  rms would be proud.

kedaha
Posts: 3521
Joined: 2008-05-24 12:26
Has thanked: 33 times
Been thanked: 77 times

Re: Hot mess of a package - who to talk to about removal?

#5 Post by kedaha »

Just to add to my previous post regarding the error in Buster:
ERROR: the templates_c directory doesn't exist or isn't writeable for the webserver.
A search in DDG found an explanation and the solution to this error or bug when using the official package (in German, which I translated with an online translator) here:
Since in the package version for Debian 10 Buster the file structure of Postfixadmin has changed, older tips to fix this bug do not work anymore. What is new is that now the directory /usr/share/postfixadmin/ should no longer be used as symlink, but only /usr/share/postfixadmin/public.

To fix the error, use the following commands to create the templates_c directory if it does not already exist (which was the case in my fresh installation) and give it the necessary access permissions:

Code: Select all

mkdir /usr/share/postfixadmin/templates_c—
chown www-data:www-data /usr/share/postfixadmin/templates_c
I can confirm [edit: 4 May] successfully completing the installation of an Bullseye email server—for testing purposes along the lines of a fairly recent Postfix-Mail-Server-Setup-on-Ubuntu-20.04 article. However, I used postfixadmin from Debian and not the latest release of postfixadmin from sourceforge net, which the author proposed, and—so far, so good—no problems yet. I still have some things to do like installing roundcube and getting interoperabilty between the passwords in postfixadmin and roundcube, but that shouldn't be a problem.
I notice postfixadmin uses md5crypt as the default to crypt the passwords although other stronger methods are available. See for example this strong-crypt-scheme-with-dovecot-postfixadmin-and-roundcube from 2016, but it doesn't exactly look like a walk in the park. :wink:
DebianStable

Code: Select all

$ vrms

No non-free or contrib packages installed on debian!  rms would be proud.

kedaha
Posts: 3521
Joined: 2008-05-24 12:26
Has thanked: 33 times
Been thanked: 77 times

Re: Hot mess of a package - who to talk to about removal?

#6 Post by kedaha »

I'd like to thank you, VA1DER for this topic because it prompted me to try the Debian postfixadmin package, for testing purposes before Bullseye goes stable. I think the bugs really amount to configuration details but I had to do quite a lot of searching to surmount them. I have the package up and running, together with roundcube, so I hope it makes its way into Bullseye stable.
I think a solution would be to update the package documentation at /usr/share/doc/postfixadmin README.Debian, where it says:
After installing the package, you should find that : http://youserver/postfixadmin/setup.php works.
But, of course, it doesn't and solving them can be quite time-consuming.
To be constructive, I'm thinking of starting a new topic to post my notes on setting up a mail server with postfixadmin, and other related matters, in Bullseye, but of course, if this package is removed, then anyone wishing to use this applcation will have to jump on the latest-available-version bandwagon, which, for all its merits, is contrary to the unstable --> testing -->stable path which I, for one, prefer to stick to.
DebianStable

Code: Select all

$ vrms

No non-free or contrib packages installed on debian!  rms would be proud.

kedaha
Posts: 3521
Joined: 2008-05-24 12:26
Has thanked: 33 times
Been thanked: 77 times

Re: Hot mess of a package - who to talk to about removal?

#7 Post by kedaha »

Just to conclude this topic.
I see the package in question" version 3.3.5-1 has been removed from testing according to postfixadmin-removed-from-testing for the main reason that it doesn't work out-of-the-box.The same could be said about other packages like, for example , wordpress, which require much more configuration than this but haven't been chucked out.
[ ...]directory called templates_c. This is not created by the
> installer and the application fails without it.
The templates_c directory is very easy to create. I had no problem in getting the package to work and a search will find for instance this article about installing postfixadmin from the Ubuntu repository here which details this creation of that directory..
So what are we to use instead of the Debian package? Brilliant solution! Just download the latest upstream tarball I suppose or use version 3.3.7-1 or any subsequent version from unstable. I notice the whohas tool shows that Ubuntu has postfixadmin 3.3.7-1 packages.ubuntu.com.
DebianStable

Code: Select all

$ vrms

No non-free or contrib packages installed on debian!  rms would be proud.

Post Reply