[ITP] Questions

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[ITP] Questions

Tim O'Callaghan
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
Reply | Threaded
Open this post in threaded view
|

Re: [ITP] Questions

Eric Blake (cygwin)
-----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             [hidden email]
-----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-----
Reply | Threaded
Open this post in threaded view
|

Re: [ITP] Questions

Max O Bowsher
In reply to this post by Tim O'Callaghan
-----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-----
Reply | Threaded
Open this post in threaded view
|

Re: [ITP] Questions

Tim O'Callaghan
In reply to this post by Eric Blake (cygwin)
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
Reply | Threaded
Open this post in threaded view
|

Re: [ITP] Questions

Christopher Faylor-2
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
Reply | Threaded
Open this post in threaded view
|

Re: [ITP] Questions

Tim O'Callaghan
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
Reply | Threaded
Open this post in threaded view
|

Re: [ITP] Questions

Christopher Faylor-2
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
Reply | Threaded
Open this post in threaded view
|

Re: [ITP] Questions

Max O Bowsher
In reply to this post by Tim O'Callaghan
-----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-----