Making a package obsolete
Jon Turney
jon.turney@dronecode.org.uk
Mon May 15 16:12:00 GMT 2017
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.
--
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
More information about the Cygwin
mailing list