On Monday 23 July 2007 03:17:40 Ralf S. Engelschall wrote: > If we would just have the "milter" package I also would vote for > renaming it to "libmilter" immediately. But what about the "milter-xxx" > packages? They use the "milter" prefix to show their correlation to the > "milter" package. Until now all "foo-bar" packages were directly related > to a central "foo" package (e.g. "perl" and "perl-xxx", "python" and > "python-xxx", etc). Sure, we can break this convention here, but is it > worth the effort? The "mimedefang" package is now already fixed and I > don't know at least about any remaining issues. > > > I see enough arguments to keep the default paths of software. The > > naming scheme for the OpenPKG packages shold reflect these. > > Yes and no. Yes, as long as it makes sense from a consistency point > of view, OpenPKG always should (and actually does AFAIK) follow the > names and paths of the upstream vendor. But, no, if the upstream vendor > decides for a path which doesn't fit very well into the filesystem > layout of OpenPKG (here the "libmilter" example would be still fine, > of course) we definetely will make it fit (and not adjust our side > according to the upstream vendor intentions). There are just too many > existing upstream vendor intentions -- if we too flexibly adjust our > filesystem layout to them, OpenPKG instances would be a mess within a > short timeframe. >
I understand that the sendmail people made a poor choice in using include/libmiter/*.h, but they did. Since enough packages do rely on the include files, I think that changing the location seems to make a lot of extra work. Now all other packages need to be patched. Whenever one of them changes, the patch may need to be updated (as the case of mimedefang). Seems to me like it would be less work and risk in the long run to leave it at the default. I can understand making changes to info, share, or man pages, but include files might not be a good idea. > So what? Who prefers... > > 1. to rename "milter" to "libmilter" despite the fact that this > breaks the OpenPKG convention of a central master package "foo" and > sub-packages "foo-bar"? > > 2. or to keep the "milter" package and the already existing "#include > <libmilter/*>" to "#include <milter/*>" patches in the "milter-xxx" > packages. > > Birger voted for (2). I personally still vote for (1) as this means > nothing to be done and to not break the conventions (although it doesn't > follow the upstream vendor intention). > > More votes? I vote for option 2 in this case. I understand that you already did the work of the patches, but I think it will cause more work/risk in the long run. That said, I will use the current implementation and I appreciate your quick response! The mimedefang package now builds! Mark Keller ______________________________________________________________________ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
