On 5/15/2017 12:20 PM, Ken Brown wrote:
The relevant code is in pkg_pkg.cygpart around lines 149--163,
especially this part:
elif (( pkg_count == 1 ))
then
pkg_contents="*"
else
pkg_contents=
We get here if PKG_CONTENTS is unset or empty.
Ken Brown writes:
> Yes, that works around the problem by not actually creating an empty
> binary tarball. But I still think cygport should allow the creation
> of an empty binary tarball by a set but empty PKG_CONTENTS.
What we should really do is make setup handle obsoletions instead of
this
On Mon, May 15, 2017 at 01:22:04PM -0400, Ken Brown wrote:
> On 5/15/2017 12:51 PM, szgyg wrote:
>> I've used the attached files to create an empty, dependencies-only package.
>
> Yes, that works around the problem by not actually creating an empty binary
> tarball. But I still think cygport
On 5/15/2017 12:51 PM, szgyg wrote:
On Mon, May 15, 2017 at 12:20:46PM -0400, Ken Brown wrote:
On 5/15/2017 11:56 AM, Jon Turney wrote:
You can always make an empty tarball called
texlive-collection-htmlxml-20170515.tar.xz or whatever, and use that for
SRC_URI.
Good idea, thanks. But it
On Mon, May 15, 2017 at 12:20:46PM -0400, Ken Brown wrote:
> On 5/15/2017 11:56 AM, Jon Turney wrote:
>> You can always make an empty tarball called
>> texlive-collection-htmlxml-20170515.tar.xz or whatever, and use that for
>> SRC_URI.
>
> Good idea, thanks. But it turns out that there's
On 15/05/2017 17:12, Brian Inglis wrote:
[intended for cygwin-apps?]
Doh! Yes.
[resending to cygwin-apps]
On 5/15/2017 11:56 AM, Jon Turney wrote:
On 15/05/2017 15:30, Ken Brown wrote:
On 5/14/2017 1:38 PM, Jon Turney wrote:
On 13/05/2017 20:44, Ken Brown wrote:
On 5/13/2017 7:12 AM, Jon Turney wrote:
On 12/05/2017 22:02, Ken Brown wrote:
I have a package that is
On 2017-05-15 09:56, Jon Turney wrote:
> On 15/05/2017 15:30, Ken Brown wrote:
>> On 5/14/2017 1:38 PM, Jon Turney wrote:
>>> On 13/05/2017 20:44, Ken Brown wrote:
On 5/13/2017 7:12 AM, Jon Turney wrote:
> On 12/05/2017 22:02, Ken Brown wrote:
>> I have a package that is going to
On 5/14/2017 1:38 PM, Jon Turney wrote:
On 13/05/2017 20:44, Ken Brown wrote:
On 5/13/2017 7:12 AM, Jon Turney wrote:
On 12/05/2017 22:02, Ken Brown wrote:
I have a package that is going to become obsolete, but its contents
will
be distributed among several other packages. So I can't handle
On 13/05/2017 20:44, Ken Brown wrote:
On 5/13/2017 7:12 AM, Jon Turney wrote:
On 12/05/2017 22:02, Ken Brown wrote:
I have a package that is going to become obsolete, but its contents will
be distributed among several other packages. So I can't handle this by
defining OBSOLETES in any one
On 5/13/2017 7:12 AM, Jon Turney wrote:
On 12/05/2017 22:02, Ken Brown wrote:
I have a package that is going to become obsolete, but its contents will
be distributed among several other packages. So I can't handle this by
defining OBSOLETES in any one .cygport file. Is there a standard way to
On 12/05/2017 22:02, Ken Brown wrote:
I have a package that is going to become obsolete, but its contents will
be distributed among several other packages. So I can't handle this by
defining OBSOLETES in any one .cygport file. Is there a standard way to
deal with this using cygport, or should
I have a package that is going to become obsolete, but its contents will
be distributed among several other packages. So I can't handle this by
defining OBSOLETES in any one .cygport file. Is there a standard way to
deal with this using cygport, or should I just create the necessary
tarballs
13 matches
Mail list logo
