If a patched version retains exactly the same version number, then I'd consider that to be a bug in the patch.As a couple notes, I would add the following expansions to this.
"Allow the widest possible version range on any module, disallowing individual malfunctioning versions to further extend the range"
I think we are better off documenting bugs in misbehaving versions of modules and perhaps offering a module check utility rather than disallowing certain versions of modules.
How do you envisage the disallowing taking place? I was actually not thinking of actively disallowing specific versions, but rather document the fact that the module doesn't work with LedgerSMB by putting a version-exclusion in our cpanfile (the canonical location to declare version dependency).
Right and my point is that this is under inclusive since it is merely an install-time check and moreover lacks any forward knowledge of later possible breakage. Also I can see possibilities where a package distributed under Debian or Gentoo might have a back ported fix and therefore it might also be over inclusive since there might be patched versions with the same version number which lack the misbehaviour.
There should be at least a suffix indicating it's patched, unless the patch is simply a change to conform with distro policy, such as a different path, or change in a library name etc.
As Erik says in his response, I don't think we need to concern ourselves too much with dependencies on packaged installs, that's up to the packager (with our support as needed during packaging)Two points:1. Please correct me if I am wrong but I don't think Debian packages change the version $VERSION when they back port fixes.That's very well possible, yes.2. This is a specific problem when installing LedgerSMB from source and packages from the distribution. I assume we want to support that.Well, yes and no. Ideally, we don't need to support this combination, because we provide packages (at least for the most popular of distributions). I see installing from source with packages from the dist as a workaround for packages not being available or sufficiently up to date.
Now assuming I am right on point 1, an important question is whether we want to take on the responsibility in the cpanfile for knowing what every distro we support has done in that area.The answer to this point - from me at least - is a firm No. People can install most packages from their distro, but if some have been blocked by us due to version mismatch, they'll have to accept that if they don't install manually for the remaining packages, `cpanm` is going to upgrade the packages which have mismatched versions. By consequence they'll need something like "local::lib".
I would ague that maybe we don't and therefore maybe the cpanfile should presume that patched versions of broken dependencies exist and we should just say "not our problem" aside from user support.Ah. But the "not our problem" can be taken two directions: over-inclusive at install-time (your solution, as I understand it), which results in non-working installations or under-inclusive at install-time (what I advocate) which results in unnecessary upgrades but is much more likely to result in working installs. My interpretation of "not our problem" is: it's not our problem that packagers don't change their version numbers (be it for good reasons or not) -- which means that we have to reject packages which *might* have been acceptable.
How the user and the user's source of the package goes about fixing the bug then becomes something we don't have to know how it works or worry about.Right. We agree there completely. But if we can't distinguish the originally broken version from the patched working version, then only packagers can solve that in the package-creation process -- which brings me to my first point: installing a mix of packages-from-dist and ledgersmb-from-source is a workaround which we should treat as such.
Agreed. However, for a packager who starts from scratch, that doesn't matter much: that packager must do all the dependencies as well as the LedgerSMB software itself. So, it doesn't reduce the work he has to do. Moreover, if things work the way they do with Debian, you have more processing time: a package needs to transition into a specific stage before you can build packages that depend on it. Which in this case means you need to build more levels of dependent packages and thus have more moments where you have to wait for the package to transition.
Pieces of software should have small, well defined responsibilities in my view. The thing is, indirect dependencies are not our responsibility so pushing more things to indirect dependencies makes our responsibility narrower, better defined, and ultimately easier to keep.The idea of spinning off the templates is actually an important case in point.While I agree with the general point of small dependency trees, I like to add a subtle addition to it:Pieces of software should have small dependency trees *compared to the functionalities they offer*.The reason I'm saying that is because I think LedgerSMB offers a huge deal of functionalities. By comparison, we can probably slightly reduce the dependency tree, but can't get it much smaller. The tree won't get smaller by separating out; it might not get much bigger either.
As long as we have to maintain these new separated modules ourselves too (as well as our packagers), then there seems to be little benefit to dependency management as a whole. Using modules like Template Toolkit makes a great deal of sense: we outsource maintenance of the software *and* dependency tree to other developers in the community, sharing the development and test efforts. Also, Template Toolkit probably was packaged before Jame ever started his work. So, there too is a benifit.As long as we're the only user (in Debian) who use our factored out libraries, the burden will fall on Jame, though.
The specific modules I would suggest we look at in the near future are the templates and the reporting engine (and actually I have immediate uses for these outside of LedgerSMB but inside the LedgerSMB ecosystem).Now if we were to have the template system outside, then we have two required modules (the successors to LedgerSMB::Template, probably, the successor to LedgerSMB::Template::HTML) which are now required. Assuming that this successor has a good plugin framework and we can auto-detect any other template library we put in, we can effectively that the LedgerSMB application no longer has any responsibility to the PDF, OpenOffice, CSV, etc. generation. If someone wants to generate spreadsheets, they do:cpan App::LedgerSMB::Template::Plug
in::OpenOffice;But we already do (for a limited set of plugins):where the syntax of the command to enable PDF support is slightly different.And away they go. We no longer worry about what dependencies this has.$ cpanm --with-feature=latex-pdf --installdeps .does exactly the same. we only specify which modules we use to make it happen. the same modules which would otherwise have been in LedgerSMB::Template::Plugin:: PDF. Both would be maintained by us, right?
It is not LedgerSMB's (the software) responsibility at all. The template engine would have to have a plugin structure that probably couldn't change much, and an interface for interacting with plugins that could not change. But this is not actually a big difficulty in that case.For pre packaged modules that's only a problem for the packager, but for git or tgz installs it's a problem for the installer.
The installer of a src version then also needs to download and install many individual modules.
Development installs will become harder, especially if different versions of a module are needed for different branches being worked on.
Finally, it will add additional load to our packagers.
Right now Jame has quite a large number of perl packages that he deals with simply to support LedgerSMB being packaged.
That can lead to delays in packaging a new LedgerSMB release if there are also changes to it's dependencies .
Having even more separate dependencies will only make that worse.I think this is actually a very valid concern. There are two very important ways we can help with that:1. we don't release a lot of new spin-offs until the old ones are really stable and we are guaranteeing compatibility for a while. If Debian has an old version of PGObject, as long as we support that interface...2. we make sure we have stable interfaces before we spin things off.I think the only way to spin off is when things are well-designed and stable indeed. Probably by having the to-be-separated-out code in exactly that state in the main code base.
_______________________________________________ devel mailing list ..hidden.. https://lists.ledgersmb.org/mailman/listinfo/devel