Re: New package standards - LAST CALL
Otmar Lendl writes in private email which I'm sure he won't mind me posting: ... What I would appreciate is, that all the Developer Ressources (Guidelines, Hints, Virtual Names, FSSTD co.) have a central WWW page where I can easily look up the currently valid standards. Could you please arrange something like that ? It makes life a LOT easier for part-time packagers. I think this would be a good idea. We already have a central FTP area, so it may be just a matter of writing the HTML page and making the dpkg SGML documentation available. What do I need to do to make the dpkg SGML documentation available ? I can cause releases of the dpkg package to upload formatted versions of the manual, but how should I package these for shipment ? The HTML versions in particular come in many files ... Ian.
Re: New package standards - LAST CALL
Michael Alan Dorman writes (Re: New package standards - LAST CALL ): In message [EMAIL PROTECTED], Ian Jackson writes: Therefore I propose that unless someone raises a serious problem or issue within the next week or two the new packaging guidelines as described in the draft dpkg programmers' manual, the draft Debian policy manual and as implemented by dpkg 1.3.x, will become official. I hate to even ask this, since if we want to make this change for the next release, but can we have just a bit more time? I have been singularly busy of late, and have only recently gotten to the point of being able to read the new docs you put up, and while everything seems sensible on paper, I worry that it we don't have people actually try it out, there's going to be some unexpected problems. I've tried very hard to leave hooks all over the place, especially in the parts where the new scheme is more automatic than the old. It won't be a disaster if we don't get everything converted. * Automation of the generation of .changes files from information in a parseable changelog and elsewhere. I have installed the changelog macros, and find they work well. Thanks. Finally, though you say the documents are just cut-n-paste from other stuff, they seem to do a better job of documenting some of the conventions that we've adopted over the last several months, WRT shared libraryies and the rest. Good. And if you're creating them from your linuxdoc-sgml hack, I'm quite interested that you make it available for others use. It seems much cleaner than the original. Or maybe that's just a function of a better conversion tool. :-). The better conversion tool helps. But having a DTD that only describes things that are actually implemented helps too. Ian.
Re: New package standards - LAST CALL
In message [EMAIL PROTECTED], Ian Jackson writes: Therefore I propose that unless someone raises a serious problem or issue within the next week or two the new packaging guidelines as described in the draft dpkg programmers' manual, the draft Debian policy manual and as implemented by dpkg 1.3.x, will become official. I hate to even ask this, since if we want to make this change for the next release, but can we have just a bit more time? I have been singularly busy of late, and have only recently gotten to the point of being able to read the new docs you put up, and while everything seems sensible on paper, I worry that it we don't have people actually try it out, there's going to be some unexpected problems. * Automation of the generation of .changes files from information in a parseable changelog and elsewhere. I have installed the changelog macros, and find they work well. Finally, though you say the documents are just cut-n-paste from other stuff, they seem to do a better job of documenting some of the conventions that we've adopted over the last several months, WRT shared libraryies and the rest. And if you're creating them from your linuxdoc-sgml hack, I'm quite interested that you make it available for others use. It seems much cleaner than the original. Or maybe that's just a function of a better conversion tool. Mike. -- Don't let me make you unhappy by failing to be contrary enough
Re: New package standards - LAST CALL
Miquel: If they don't react [to the request to convert to the new source package] in say 2 weeks, someone else can do it (I'll take some) like David did during the transition from a.out to ELF. Thanks for volunteering! Please make sure to merge the multi-architecture patches while you do that. would it be possible to look for an additional architecture dependant patch? For example, if you have bash-1.14.6-1.dsc bash-1.14.6-1.EXTRA.alpha.diff.gz I strongly prefer only one patch per package. I'd prefer the architecture-specific stuff to be in the one main patch, with ifdefs, etc. if necessary. One reason is that there is rarely a patch to user code that is necessary for only _one_ architecture. Either it's word-size, or endian-ness, or something else that is going to be necessary for ultra-sparc as well as alpha, etc. A second reason is that it's nice for the packager to be able to see all of the Debian changes at once. Otherwise, it would be too easy to make incompatible changes that are only caught when we go to build on the architecture that has its own patches. Thanks Bruce
Re: New package standards - LAST CALL
Ian Jackson: Therefore I propose that unless someone raises a serious problem or issue within the next week or two the new packaging guidelines as described in the draft dpkg programmers' manual, the draft Debian policy manual and as implemented by dpkg 1.3.x, will become official. I delegate fiat power to you for the issue of the source package format. Make it final when you feel it's ready. Thanks Bruce
Re: New package standards - LAST CALL
You (Bruce Perens) wrote: Miquel: If they don't react [to the request to convert to the new source package] in say 2 weeks, someone else can do it (I'll take some) like David did during the transition from a.out to ELF. Thanks for volunteering! Please make sure to merge the multi-architecture patches while you do that. Why do you think I'm volunteering :) I have ported all the base packages to Debian/Alpha and there are a lot of diffs to merge in anyway. It's probably easier for me to repackage everything and upload it then to get all the maintainers to accept my patches. Well faster anyway. As an added bonus all these packages then have GNU libc support so when libc6 comes out for the i386 it will be just a matter of recompiling. Expect the first Debian/Alpha machine on the net later today or tomorrow ! Mike. -- Miquel van| Cistron Internet Services --Alphen aan den Rijn. Smoorenburg, | mailto:[EMAIL PROTECTED] http://www.cistron.nl/ [EMAIL PROTECTED] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)
Re: New package standards - LAST CALL
Miquel van Smoorenburg writes (Re: New package standards - LAST CALL): ... I also think that when you make the new source package official, we should warn all maintainers of the base packages and ask them to convert their packages to the new standard. If they don't react in say 2 weeks, someone else can do it (I'll take some) like David did during the transition from a.out to ELF. Yes. If a few people do a lot of packages it's probably quicker and less error-prone, anyway, then having the maintainers do it themselves. On the other hand having the maintainers do it themselves will get them to learn the ropes ... ... Well, one other idea. Since the original source and the patch are kept in the archive, would it be possible to look for an additional architecture dependant patch? [...] No. Any architecture dependencies should be avoided; if they can't they should be dealt with at build-time in the package itself, rather than by making several versions of the package. [..] It would be a tremendous advantage when porting to a new architecture - the porter need only supply the extra patch to the debian archive and it will just work. Also, the patch will be in a public place so that the original maintainer can integrate the patch in the next version of the package. The porter should make an architecture-independent patch (ie, one that will work on any architecture) and then either: (a) add `.1' to the Debian revision and release a new source package with their binaries - they should send the patch to the original maintainer for inclusion, too; or (a) send the patch to the main maintainer (or to [EMAIL PROTECTED]) and wait for it to be included. Ian.
