* Making a package obsolete
@ 2017-05-12 21:02 Ken Brown
2017-05-13 11:12 ` Jon Turney
0 siblings, 1 reply; 13+ messages in thread
From: Ken Brown @ 2017-05-12 21:02 UTC (permalink / raw)
To: cygwin-apps
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 and .hint file manually?
Ken
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Making a package obsolete
2017-05-12 21:02 Making a package obsolete Ken Brown
@ 2017-05-13 11:12 ` Jon Turney
2017-05-13 19:44 ` Ken Brown
0 siblings, 1 reply; 13+ messages in thread
From: Jon Turney @ 2017-05-13 11:12 UTC (permalink / raw)
To: cygwin-apps; +Cc: Ken Brown
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 just create the necessary
> tarballs and .hint file manually?
I think the best way to do that is to bump your package revision, change
it's category to _obsolete, make it's contents empty, and make it depend
on the packages which are replacing it.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Making a package obsolete
2017-05-13 11:12 ` Jon Turney
@ 2017-05-13 19:44 ` Ken Brown
2017-05-14 17:39 ` Jon Turney
0 siblings, 1 reply; 13+ messages in thread
From: Ken Brown @ 2017-05-13 19:44 UTC (permalink / raw)
To: Jon Turney, cygwin-apps
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
>> deal with this using cygport, or should I just create the necessary
>> tarballs and .hint file manually?
>
> I think the best way to do that is to bump your package revision, change
> it's category to _obsolete, make it's contents empty, and make it depend
> on the packages which are replacing it.
Yes, that was my first thought. But there's no longer a source file for
the obsolete package[1], and cygport complains that SRC_URI must be
defined. Maybe cygport should be patched to allow an empty SRC_URI when
the category is _obsolete. Or do you see another way around this?
Ken
The package in question is texlive-collection-htmlxml, which no longer
exists upstream.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Making a package obsolete
2017-05-13 19:44 ` Ken Brown
@ 2017-05-14 17:39 ` Jon Turney
2017-05-15 14:30 ` Ken Brown
0 siblings, 1 reply; 13+ messages in thread
From: Jon Turney @ 2017-05-14 17:39 UTC (permalink / raw)
To: cygwin-apps; +Cc: Ken Brown
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 .cygport file. Is there a standard way to
>>> deal with this using cygport, or should I just create the necessary
>>> tarballs and .hint file manually?
>>
>> I think the best way to do that is to bump your package revision, change
>> it's category to _obsolete, make it's contents empty, and make it depend
>> on the packages which are replacing it.
>
> Yes, that was my first thought. But there's no longer a source file for
> the obsolete package[1], and cygport complains that SRC_URI must be
> defined. Maybe cygport should be patched to allow an empty SRC_URI when
> the category is _obsolete. Or do you see another way around this?
I would think you can use the same SRC_URI as previously, but set
PKG_CONTENTS="" and PKG_IGNORE="*" ?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Making a package obsolete
2017-05-14 17:39 ` Jon Turney
@ 2017-05-15 14:30 ` Ken Brown
[not found] ` <20762138-fb8e-3842-6b06-928f264b4549@dronecode.org.uk>
0 siblings, 1 reply; 13+ messages in thread
From: Ken Brown @ 2017-05-15 14:30 UTC (permalink / raw)
To: Jon Turney, cygwin-apps
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 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 and .hint file manually?
>>>
>>> I think the best way to do that is to bump your package revision, change
>>> it's category to _obsolete, make it's contents empty, and make it depend
>>> on the packages which are replacing it.
>>
>> Yes, that was my first thought. But there's no longer a source file for
>> the obsolete package[1], and cygport complains that SRC_URI must be
>> defined. Maybe cygport should be patched to allow an empty SRC_URI when
>> the category is _obsolete. Or do you see another way around this?
>
> I would think you can use the same SRC_URI as previously, but set
> PKG_CONTENTS="" and PKG_IGNORE="*" ?
You're right, I can do something like that. I was being overly pedantic
in wanting SRC_URI to be "accurate". Sorry for the noise.
Ken
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Making a package obsolete
[not found] ` <20762138-fb8e-3842-6b06-928f264b4549@dronecode.org.uk>
@ 2017-05-15 16:13 ` Brian Inglis
2017-05-15 16:26 ` Jon Turney
2017-05-15 16:20 ` Ken Brown
1 sibling, 1 reply; 13+ messages in thread
From: Brian Inglis @ 2017-05-15 16:13 UTC (permalink / raw)
To: cygwin-apps
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 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 and .hint file manually?
>>>>>
>>>>> I think the best way to do that is to bump your package revision,
>>>>> change
>>>>> it's category to _obsolete, make it's contents empty, and make it
>>>>> depend
>>>>> on the packages which are replacing it.
>>>>
>>>> Yes, that was my first thought. But there's no longer a source file
>>>> for
>>>> the obsolete package[1], and cygport complains that SRC_URI must be
>>>> defined. Maybe cygport should be patched to allow an empty SRC_URI
>>>> when
>>>> the category is _obsolete. Or do you see another way around this?
>>>
>>> I would think you can use the same SRC_URI as previously, but set
>>> PKG_CONTENTS="" and PKG_IGNORE="*" ?
>>
>> You're right, I can do something like that. I was being overly pedantic
>> in wanting SRC_URI to be "accurate". Sorry for the noise.
>
> You can always make an empty tarball called
> texlive-collection-htmlxml-20170515.tar.xz or whatever, and use that for
> SRC_URI.
[intended for cygwin-apps?]
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Making a package obsolete
[not found] ` <20762138-fb8e-3842-6b06-928f264b4549@dronecode.org.uk>
2017-05-15 16:13 ` Brian Inglis
@ 2017-05-15 16:20 ` Ken Brown
2017-05-15 16:51 ` szgyg
2017-05-16 17:52 ` Ken Brown
1 sibling, 2 replies; 13+ messages in thread
From: Ken Brown @ 2017-05-15 16:20 UTC (permalink / raw)
To: cygwin-apps
[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 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 and .hint file manually?
>>>>>
>>>>> I think the best way to do that is to bump your package revision,
>>>>> change
>>>>> it's category to _obsolete, make it's contents empty, and make it
>>>>> depend
>>>>> on the packages which are replacing it.
>>>>
>>>> Yes, that was my first thought. But there's no longer a source file
>>>> for
>>>> the obsolete package[1], and cygport complains that SRC_URI must be
>>>> defined. Maybe cygport should be patched to allow an empty SRC_URI
>>>> when
>>>> the category is _obsolete. Or do you see another way around this?
>>>
>>> I would think you can use the same SRC_URI as previously, but set
>>> PKG_CONTENTS="" and PKG_IGNORE="*" ?
>>
>> You're right, I can do something like that. I was being overly pedantic
>> in wanting SRC_URI to be "accurate". Sorry for the noise.
>
> 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 another problem:
cygport won't actually create an empty binary tarball in this situation.
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. (There's actually no
test to see if it's set but empty.) In the situation under discussion,
this results in pkg_contents="*" followed by a tar error.
Yaakov, shouldn't the user be allowed to explicitly set PKG_CONTENTS
empty and have cygport honor that, at least for obsolete packages?
Ken
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Making a package obsolete
2017-05-15 16:13 ` Brian Inglis
@ 2017-05-15 16:26 ` Jon Turney
0 siblings, 0 replies; 13+ messages in thread
From: Jon Turney @ 2017-05-15 16:26 UTC (permalink / raw)
To: cygwin-apps
On 15/05/2017 17:12, Brian Inglis wrote:
> [intended for cygwin-apps?]
Doh! Yes.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Making a package obsolete
2017-05-15 16:20 ` Ken Brown
@ 2017-05-15 16:51 ` szgyg
2017-05-15 17:21 ` Ken Brown
2017-05-16 17:52 ` Ken Brown
1 sibling, 1 reply; 13+ messages in thread
From: szgyg @ 2017-05-15 16:51 UTC (permalink / raw)
To: cygwin-apps
[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]
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 another problem: cygport
> won't actually create an empty binary tarball in this situation.
>
> 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. (There's actually no test to
> see if it's set but empty.) In the situation under discussion, this results
> in pkg_contents="*" followed by a tar error.
>
> Yaakov, shouldn't the user be allowed to explicitly set PKG_CONTENTS empty
> and have cygport honor that, at least for obsolete packages?
I've used the attached files to create an empty, dependencies-only package.
szgyg
[-- Attachment #2: dependencies.cygport --]
[-- Type: text/plain, Size: 255 bytes --]
NAME="dependencies"
VERSION="0"
RELEASE="0"
SUMMARY="dependencies (Metapackage)"
CATEGORY="Devel"
REQUIRES="" # put stuff here
####################
SRC_URI="empty.tar.gz"
SRC_DIR="empty"
KEEPDIRS="/usr"
src_compile() { : ; }
src_install() { : ; }
[-- Attachment #3: empty.tar.gz --]
[-- Type: application/x-tar-gz, Size: 123 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Making a package obsolete
2017-05-15 16:51 ` szgyg
@ 2017-05-15 17:21 ` Ken Brown
2017-05-15 18:00 ` szgyg
2017-05-15 18:18 ` Achim Gratz
0 siblings, 2 replies; 13+ messages in thread
From: Ken Brown @ 2017-05-15 17:21 UTC (permalink / raw)
To: cygwin-apps
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 turns out that there's another problem: cygport
>> won't actually create an empty binary tarball in this situation.
>>
>> 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. (There's actually no test to
>> see if it's set but empty.) In the situation under discussion, this results
>> in pkg_contents="*" followed by a tar error.
>>
>> Yaakov, shouldn't the user be allowed to explicitly set PKG_CONTENTS empty
>> and have cygport honor that, at least for obsolete packages?
>
> 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 should allow the creation of
an empty binary tarball by a set but empty PKG_CONTENTS.
Ken
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Making a package obsolete
2017-05-15 17:21 ` Ken Brown
@ 2017-05-15 18:00 ` szgyg
2017-05-15 18:18 ` Achim Gratz
1 sibling, 0 replies; 13+ messages in thread
From: szgyg @ 2017-05-15 18:00 UTC (permalink / raw)
To: cygwin-apps
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 should allow the creation of an empty
> binary tarball by a set but empty PKG_CONTENTS.
Yeah, it creates a tarball with an empty usr/ directory. What I would
really like is a cygclass for empty packages.
szgyg
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Making a package obsolete
2017-05-15 17:21 ` Ken Brown
2017-05-15 18:00 ` szgyg
@ 2017-05-15 18:18 ` Achim Gratz
1 sibling, 0 replies; 13+ messages in thread
From: Achim Gratz @ 2017-05-15 18:18 UTC (permalink / raw)
To: cygwin-apps
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 empty-install-package dance.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Making a package obsolete
2017-05-15 16:20 ` Ken Brown
2017-05-15 16:51 ` szgyg
@ 2017-05-16 17:52 ` Ken Brown
1 sibling, 0 replies; 13+ messages in thread
From: Ken Brown @ 2017-05-16 17:52 UTC (permalink / raw)
To: cygwin-apps
[-- Attachment #1: Type: text/plain, Size: 684 bytes --]
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. (There's actually no
> test to see if it's set but empty.) In the situation under discussion,
> this results in pkg_contents="*" followed by a tar error.
>
> Yaakov, shouldn't the user be allowed to explicitly set PKG_CONTENTS
> empty and have cygport honor that, at least for obsolete packages?
The attached patch implements this, and not just for obsolete packages.
Ken
[-- Attachment #2: 0001-Honor-the-PKG_CONTENTS-variable-if-it-is-set-even-if.patch --]
[-- Type: text/plain, Size: 857 bytes --]
From e6c3f77e9b9c2e0767c0c098111531157e639309 Mon Sep 17 00:00:00 2001
From: Ken Brown <kbrown@cornell.edu>
Date: Tue, 16 May 2017 13:46:30 -0400
Subject: [PATCH] Honor the PKG_CONTENTS variable if it is set, even if it is
empty
---
lib/pkg_pkg.cygpart | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/pkg_pkg.cygpart b/lib/pkg_pkg.cygpart
index c59b9aa2..5008eadd 100644
--- a/lib/pkg_pkg.cygpart
+++ b/lib/pkg_pkg.cygpart
@@ -146,10 +146,10 @@ __pkg_binpkg() {
*) distsubdir=${pkg_name[${n}]} ;;
esac
- if defined ${pkg_contents_var}
+ if [ "${!pkg_contents_var+set}" = "set" ]
then
pkg_contents=${!pkg_contents_var}
- elif defined PKG_CONTENTS[${n}]
+ elif [ "${PKG_CONTENTS[${n}]+set}" = "set" ]
then
pkg_contents=${PKG_CONTENTS[${n}]}
elif [ -f ${C}/${pkg_list[${n}]}.list ]
--
2.12.3
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2017-05-16 17:52 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-12 21:02 Making a package obsolete Ken Brown
2017-05-13 11:12 ` Jon Turney
2017-05-13 19:44 ` Ken Brown
2017-05-14 17:39 ` Jon Turney
2017-05-15 14:30 ` Ken Brown
[not found] ` <20762138-fb8e-3842-6b06-928f264b4549@dronecode.org.uk>
2017-05-15 16:13 ` Brian Inglis
2017-05-15 16:26 ` Jon Turney
2017-05-15 16:20 ` Ken Brown
2017-05-15 16:51 ` szgyg
2017-05-15 17:21 ` Ken Brown
2017-05-15 18:00 ` szgyg
2017-05-15 18:18 ` Achim Gratz
2017-05-16 17:52 ` Ken Brown
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).