* Ken Moffat <[email protected]> wrote: Hi,
> On a quick look, I can't see the point of these rules. So, I have > to ask - "What is/are the problem(s) you are trying to solve ?" this comes from my experiences and problems in package/distro maintenance over the last decade, which would have been prevented if the upstream did follow that rules ;-p > In particular, I don't understand this one under canonic(al) package > name - well, it has to be unique (to prevent conflicts with other packages) and doesnt change arbitrarily. (for example it should not contain any "-", etc) > It MUST change if there is an major branch break, so upcoming > releases are incompatible and conflicting to previous releases. That's an very interesting inssue. For really major interface breaks (in fact: new interfaces), such as on glib-1.x -> glib-2.x I'd really suggest adding the generation number to the name, eg. calling it "glib2" (although didnt state it in the document yet). In general, interfaces should never break backwards API compatibility, better create a new interface and leave alone the old one ;-p > My interests are desktop packages - I'd much rather have a > _correctly_ documented way of getting rid of the static libs. That could be easily done by filtering the installed tree before merging into target image or packing into the binpkg file, same as stripping, removing build-time stuff, etc - as long as everything's installed into proper locations. > But asking for the documentation in configure scripts to be > kept up to date is pie in the sky, and a waste of electrons > (and of developers' time). It's practically the same issue as documenting the source code. The point here is that it allows extracting the documentation (and presenting it at proper places) can be down by programs. For example, I'd let my buildsystem check for changed configure help output and issue a big warning then. > You also single out what autoconf-based packages ought to do. > Surely the bigger problem these days is the packages using other > build systems such as cmake ? Well, autoconf-based packages are the vast majority (at least for those I had to cope with), so I had biggest presure here. Other make systems will follow. (note: this document is still work-in-progress) > I have to say that I'm not really concerned about how easy or hard > packages are to reliably build and install - if they're too hard, I > drop them (so goodbye, kde4). Sure. I'm feeling the same, especially w/ kde or gnome. There would be enormously work to do, until it gets anywhere near to be distro- maintenable ;-p > Also, you make no mention of fake installs - most packages use > DESTDIR these days. Those which don't are often a pain if you don't > want to let it do it's own thing for 'make install' when you have no > idea what it is going to do. Yes, of course. But that's an builder-type specific issue, for autoconf I already stated that. As said: that document is a work-in-progress - rules for make-based packages will follow next. Feel free to contribute :) cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: [email protected] mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ---------------------------------------------------------------------- -- http://linuxfromscratch.org/mailman/listinfo/lfs-chat FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
