ok checked the debian package and seems pretty outdated.. debian are on 1.0.16 respect 1.1.X from current series on upstream..
Debian move away from FAM to Gamin on 1.0.15 and stabilize on 1.0.16-3 those changes are not so great just focus on gamin, upstream on 1.1.X moved to inotify so then yes debian packages still uses fam/gamin unfortunately > PICCORO McKAY Lenz writes: > > > The current versions can be built directly to installable .debs from the > > For you SAM unfortunatelly this will break many things on debian for > My .deb packages are not upgrades. They are alternate builds. In your packages, your configuration separates too many packages into various configurations without taking into account if there are changes, for example courier-webadmin-apache2 but I don't see for lighttpd or nginx that they are much more efficient than the fat apache2, and even so the package just places the configurations but does not take into account if it was altered in updates or upgrades .. as owrse, if there a system upgrade (mayor with stdlib and libc6 linking) your packages totally do not handle this as mooth, just we must complety removed to again reinstall Sam, debian packages follow standards to integrate into the system, taking into accoutn the mayor and minor upgrades.. very valuable for production sites.. In conclusion your packages are more "easy to produce" rather than "easy to manage in upgrades", especially major upgrades when the whole system changes.. I hope you understand. Robert, your patch may help stable packages but noted the obtuse position of SAM i will try to made backports in venenux repositories for older release in some weeks.. NOTE ABOUT MAILDROP AND WEBADMIN: those are provided, maildrop just packages separatelly, and webadmin in build in. webadmin is just a cgi-bin a separate package for that is unnecessary but maildrop need helps and clarifications, cos seems way-builds affects the behaviour.. > > Besides, nobody is forced to do anything. Everyone is free to stay on the > Debian's existing packages. But if they want to build .debs directly from > the released tarball, that's the cost of doing so. > > Debian packages do not include maildrop and sqwebmail subpackages. Instead > maildrop and sqwebmail get built from their own tarballs. And, periodic > someone comes in here wondering about subtle issues because of that. This is > an error in Debian's packaging. > > Also, I don't see a webadmin subpackage, perhaps webadmin is included in the > main one, but it should be a subpackage. Also my package builds separate > subpackages with the apache configuration. If apache is installed, > installing Courier automatically installs apache configuration files, all > that's needed is the a2enconf command to enable sqwebmail, mlm, and webadmin. > > Perhaps Debian's main courier/sqwebmail packages manually install apache > configuration files, if apache is already installed. Even if they do that, > the subpackage-based approach is just so much better, in many ways. For > example: if apache is not initially installed, but gets installed later, > then installing the apache subpackages will automatically configure > sqwebmail/mlm/webadmin. A subpackage-based approach for this is, in my view, > undisputably better. > > > > rebuilding all dependencies, courier-unicode and courier-authlib; as well > > as > > > uninstalling and purging the old debs. These debs are not compatible with > > > the Debian-provided ones. > > > > i do not recommend this unless such packages can be in sync with debian > > ones... > > My packages are not meant to be in sync, but be an alternate build. Choice > is good, it's never bad. > > > but seems you SAM neither the debina packager are in sync ... > > My packages's purposes is not to be synchronized with Debian ones'. > > > debian has a EXCELLENT upgrade and maintenance system, your packages > > I don't know what that means. My packages get built directly from the source > tarball, and new versions, once they release and come out, should build > directly into updated .debs, that will update via apt, normally, just like > any other package. You can put them in your local apt repo, using aptly or > similar, and 'apt upgrade' will pull them in just like any other deb. > > It's really a simple as > > tar xf courier-<version>.tar.bz2 > cd courier-<version> > sh -vx ./courier-debuild > mv deb/*.deb <somewhere> > sudo apt update > sudo apt upgrade > > Write a script that does something like this, and then puts the resulting > built debs into your local apt repository, that's already configured in > sources.list. That's just a one-time setup. Now, you've got a turnkey system > that can quickly update to a new release, without waiting for Debian's > packaging to catch up. > > > just removes and put new files.. does nto take care of the system > > changes respect non-system changes,, in resume those pacakges you > > recommend to use are not good for production sites > > My packages will update just fine on their own, but they are not meant to > update Debian ones. This is an alternate build, whose configuration is > aligned closer to the package's defaults, rather than Debian's. > > _______________________________________________ > Courier-imap mailing list > Courier-imap@lists.sourceforge.net > Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap _______________________________________________ Courier-imap mailing list Courier-imap@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
