[ITP] Questions
Hi, Sorry about the delay with getting back to this stuff. I'd like to ask a few quick questions before i send my formal ITP's 1) should i send a separate ITP email for each one or one for all of them? 2) bundling - If i need to include a new tool/lib to support a particular feature such as String::ShellQuote or CVSps, should i bundle it in or separate it out? are there guidelines? 3) If a package needs a specific tool to build it, such as asciidoc being needed for git documentation, does it also need to be supported or not? if so does it need to be bundled with the source, or as a separate package? cheers, Tim. However beautiful the strategy, you should occasionally look at the results. -- Winston Churchill
Re: [ITP] Questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Tim O'Callaghan on 11/18/2005 4:04 AM: I'd like to ask a few quick questions before i send my formal ITP's 1) should i send a separate ITP email for each one or one for all of them? If they are for related packages, one email will do (look at yesterday's upload request for multiple xemacs packages, for example). 2) bundling - If i need to include a new tool/lib to support a particular feature such as String::ShellQuote or CVSps, should i bundle it in or separate it out? are there guidelines? If the feature is useful on its own, it is worth considering a separate package. But as the package proposer, you have some freedom here to do what you think is best, then you can ask for some feedback as to whether your proposed layout actually made sense. 3) If a package needs a specific tool to build it, such as asciidoc being needed for git documentation, does it also need to be supported or not? if so does it need to be bundled with the source, or as a separate package? In general, we like the ability to reproduce a build using cygwin packages. This has not always been the case, but cygwin is now self-sustaining enough that you can rebuild almost all cygwin packages using just cygwin (cross-compiling would be hands down faster, but it is the principle of the thing). I would consider proposing asciidoc as a separate package, again because it might prove useful outside of git. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDfc+q84KuGfSFAYARAuwNAJsEvEm7vXEzz5y4h3O4/B5yblegswCfeHiG SpjLb7HB+S9vRHmK0AGiw68= =cEN7 -END PGP SIGNATURE-
Re: [ITP] Questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim O'Callaghan wrote: Hi, Sorry about the delay with getting back to this stuff. I'd like to ask a few quick questions before i send my formal ITP's 1) should i send a separate ITP email for each one or one for all of them? Choose based on whether it makes sense for them to be discussed as a unit, or not. If packages are entirely unrelated, use separate emails. Combine multiple packages into a single ITP mail if it makes little sense for one to be added to the Cygwin distro without the other. 2) bundling - If i need to include a new tool/lib to support a particular feature such as String::ShellQuote or CVSps, should i bundle it in or separate it out? are there guidelines? Separate packages are nicer, because then you can update the tool/lib without updating the 'parent' package, and vice versa. Plus, there's always the possibility another package might want to depend on the tool/lib later. 3) If a package needs a specific tool to build it, such as asciidoc being needed for git documentation, does it also need to be supported or not? if so does it need to be bundled with the source, or as a separate package? It really ought to be possible to rebuild any Cygwin package using only software available as Cygwin packages, so a package would be preferable. Separately - the answer to 2) applies equally here too. Max. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) iD8DBQFDfdN5fFNSmcDyxYARAg29AJ9XtPak16gfcQ20lOhjFL/MhuECEwCgrKXA KArsHvi7oenlEqx8k4UC9go= =Syzp -END PGP SIGNATURE-
Re: [ITP] Questions
On Fri, Nov 18, 2005 at 05:57:14AM -0700, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 3) If a package needs a specific tool to build it, such as asciidoc being needed for git documentation, does it also need to be supported or not? if so does it need to be bundled with the source, or as a separate package? In general, we like the ability to reproduce a build using cygwin packages. This has not always been the case, but cygwin is now self-sustaining enough that you can rebuild almost all cygwin packages using just cygwin (cross-compiling would be hands down faster, but it is the principle of the thing). I would consider proposing asciidoc as a separate package, again because it might prove useful outside of git. Ok. I'll set it up as a separate package. I was thinking about the current distro method, its probably a stupid question, but i was wondering why don't you support, or have tools to convert rpm/dpkg type build packages? Cygwin seems to have native rpm dpkg tools and most source packages have a 'dist' type target... Tim. However beautiful the strategy, you should occasionally look at the results. -- Winston Churchill
Re: [ITP] Questions
On Fri, Nov 18, 2005 at 03:14:59PM +0100, Tim O'Callaghan wrote: I was thinking about the current distro method, its probably a stupid question, but i was wondering why don't you support, or have tools to convert rpm/dpkg type build packages? Cygwin seems to have native rpm dpkg tools and most source packages have a 'dist' type target... There's no mystery here. We're all just mean SOBs who like to make things as hard as possible for people. What other reason could there be for the lack of existence of something in a free software project? cgf
Re: [ITP] Questions
On Fri, Nov 18, 2005 at 10:05:07AM -0500, Christopher Faylor wrote: On Fri, Nov 18, 2005 at 03:14:59PM +0100, Tim O'Callaghan wrote: I was thinking about the current distro method, its probably a stupid question, but i was wondering why don't you support, or have tools to convert rpm/dpkg type build packages? Cygwin seems to have native rpm dpkg tools and most source packages have a 'dist' type target... There's no mystery here. We're all just mean SOBs who like to make things as hard as possible for people. I thought as much. What other reason could there be for the lack of existence of something in a free software project? Lack of someone bothered enough by the problem to do anything about it, is the usual reason ;) Tim. However beautiful the strategy, you should occasionally look at the results. -- Winston Churchill
Re: [ITP] Questions
On Fri, Nov 18, 2005 at 04:48:34PM +0100, Tim O'Callaghan wrote: On Fri, Nov 18, 2005 at 10:05:07AM -0500, Christopher Faylor wrote: On Fri, Nov 18, 2005 at 03:14:59PM +0100, Tim O'Callaghan wrote: I was thinking about the current distro method, its probably a stupid question, but i was wondering why don't you support, or have tools to convert rpm/dpkg type build packages? Cygwin seems to have native rpm dpkg tools and most source packages have a 'dist' type target... There's no mystery here. We're all just mean SOBs who like to make things as hard as possible for people. I thought as much. What other reason could there be for the lack of existence of something in a free software project? Lack of someone bothered enough by the problem to do anything about it, is the usual reason ;) Bingo! cgf
Re: [ITP] Questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim O'Callaghan wrote: On Fri, Nov 18, 2005 at 05:57:14AM -0700, Eric Blake wrote: 3) If a package needs a specific tool to build it, such as asciidoc being needed for git documentation, does it also need to be supported or not? if so does it need to be bundled with the source, or as a separate package? In general, we like the ability to reproduce a build using cygwin packages. This has not always been the case, but cygwin is now self-sustaining enough that you can rebuild almost all cygwin packages using just cygwin (cross-compiling would be hands down faster, but it is the principle of the thing). I would consider proposing asciidoc as a separate package, again because it might prove useful outside of git. Ok. I'll set it up as a separate package. I was thinking about the current distro method, its probably a stupid question, but i was wondering why don't you support, or have tools to convert rpm/dpkg type build packages? Cygwin seems to have native rpm dpkg tools and most source packages have a 'dist' type target... Leaving aside the SHTDI issue that has already been discussed, I'm not sure this would be as useful as it sounds. The generic-build-script does quite a few little things like autoinstalling certain doc files, helping out with pre/postinstall scripts, providing default configure args to put files in the standard Cygwin places. All of which would be missed out if you used the package's own idea of how to package things. The main configure/make/install buildsystem of a package is often better maintained than bundled RPM specfiles, etc. Also, as far as Cygwin's rpm/dpkg tools go: dpkg is maintainerless and slated for removal, and current upstream versions of RPM die before entering main(), when compiled on Cygwin. Max. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) iD8DBQFDfg2ifFNSmcDyxYARAizDAKDD47o8OV+5qw9p9y1LilvQGYQQlACcD/W3 JFh2UCd+hXUnCIg2cdlm53s= =T5pQ -END PGP SIGNATURE-
