Re: [RFC] cygport: PKG_OBSOLETES
Warren Young writes: $ git clone git://cygwin-ports.git.sourceforge.net/cygwin-ports/cygport Cloning into 'cygport'... fatal: The remote end hung up unexpectedly What am I missing? Try this repository URL: git://cygwin-ports.git.sourceforge.net/gitroot/cygwin-ports/cygport Or this mirror: git://repo.or.cz/cygport.git http://repo.or.cz/r/cygport.git Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
Re: [RFC] cygport: PKG_OBSOLETES
On 7/25/2013 22:31, Warren Young wrote: On 7/25/2013 20:31, Yaakov (Cygwin/X) wrote: On 2013-07-25 14:50, Warren Young wrote: I'll wait for this PKG_OBSOLETES feature to ship in Cygport, and be a guinea pig for it. It's in git master already. $ git clone git://cygwin-ports.git.sourceforge.net/cygwin-ports/cygport Cloning into 'cygport'... fatal: The remote end hung up unexpectedly What am I missing?
Re: [RFC] cygport: PKG_OBSOLETES
On Jul 24 14:38, Warren Young wrote: On 7/24/2013 05:41, Corinna Vinschen wrote: On Jul 24 05:12, Warren Young wrote: You'd have to fake a -3 package set, with libexpat-devel-3 set to obsolete libexpat1-devel-2, so that package developers would automatically get new packages on their next Cygwin update. If you're willing to do that for 32 and 64 bit, ok. I don't see what you need from me. Can't you just copy *-2* to *-3* except for libexpat1-devel*-2* which becomes libexpat-devel*-3*, then manually change all the *.hint files referencing libexpat1-devel? I mean, if I rebuild my packages here using the new .cygport file I posted, aren't I going to get exactly the same output tarballs as before, just with different names? The content of the src packages won't match the new version if we just copy the files. A rebuild is simplest and cleanest. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [RFC] cygport: PKG_OBSOLETES
On 7/25/2013 02:30, Corinna Vinschen wrote: On Jul 24 14:38, Warren Young wrote: On 7/24/2013 05:41, Corinna Vinschen wrote: On Jul 24 05:12, Warren Young wrote: You'd have to fake a -3 package set, with libexpat-devel-3 set to obsolete libexpat1-devel-2, so that package developers would automatically get new packages on their next Cygwin update. If you're willing to do that for 32 and 64 bit, ok. ...aren't I going to get exactly the same output tarballs as before, just with different names? The content of the src packages won't match the new version if we just copy the files. A rebuild is simplest and cleanest. Okay. I'll wait for this PKG_OBSOLETES feature to ship in Cygport, and be a guinea pig for it.
Re: [RFC] cygport: PKG_OBSOLETES
On 7/25/2013 3:50 PM, Warren Young wrote: On 7/25/2013 02:30, Corinna Vinschen wrote: On Jul 24 14:38, Warren Young wrote: On 7/24/2013 05:41, Corinna Vinschen wrote: On Jul 24 05:12, Warren Young wrote: You'd have to fake a -3 package set, with libexpat-devel-3 set to obsolete libexpat1-devel-2, so that package developers would automatically get new packages on their next Cygwin update. If you're willing to do that for 32 and 64 bit, ok. ...aren't I going to get exactly the same output tarballs as before, just with different names? The content of the src packages won't match the new version if we just copy the files. A rebuild is simplest and cleanest. Okay. I'll wait for this PKG_OBSOLETES feature to ship in Cygport, and be a guinea pig for it. While you're waiting, could you provide a setup.hint for libexpat1-devel (64 bit)? Without a setup.hint, it gets put into the Misc category and is then installed by default. Ken
Re: [RFC] cygport: PKG_OBSOLETES
On 7/25/2013 15:33, Ken Brown wrote: could you provide a setup.hint for libexpat1-devel (64 bit)? Without a setup.hint, it gets put into the Misc category and is then installed by default. I don't know what you're talking about. Here's the setup.hint I RFU'd: category: Libs requires: cygwin libexpat1 external-source: expat sdesc: Expat XML parser library (development) ldesc: This is Expat, a C library for parsing XML, written by James Clark. Expat is a stream-oriented XML parser. This means that you register handlers with the parser before starting the parse. These handlers are called when the parser discovers the associated structures in the document being parsed. A start tag is an example of the kind of structures for which you may register handlers. Doesn't the first line do what you want?
Re: [RFC] cygport: PKG_OBSOLETES
On 7/25/2013 7:01 PM, Warren Young wrote: On 7/25/2013 15:33, Ken Brown wrote: could you provide a setup.hint for libexpat1-devel (64 bit)? Without a setup.hint, it gets put into the Misc category and is then installed by default. I don't know what you're talking about. Here's the setup.hint I RFU'd: Here's your RFU: wget -e robots=off --cut-dirs=2 -np -nH -A'*2.1.0-2*' -r \ http://etr-usa.com/cygwin64/expat/ There are no setup.hint files in it. All packages except libexpat1-devel have a setup.hint on sourceware anyway because Yaakov's initial upload of expat-2.1.0-1 included setup.hint files. category: Libs requires: cygwin libexpat1 external-source: expat sdesc: Expat XML parser library (development) ldesc: This is Expat, a C library for parsing XML, written by James Clark. Expat is a stream-oriented XML parser. This means that you register handlers with the parser before starting the parse. These handlers are called when the parser discovers the associated structures in the document being parsed. A start tag is an example of the kind of structures for which you may register handlers. I've just added this on sourceware. Ken
Re: [RFC] cygport: PKG_OBSOLETES
On 2013-07-25 14:50, Warren Young wrote: I'll wait for this PKG_OBSOLETES feature to ship in Cygport, and be a guinea pig for it. It's in git master already. Yaakov
Re: [RFC] cygport: PKG_OBSOLETES
On 7/25/2013 17:36, Ken Brown wrote: Here's your RFU: wget -e robots=off --cut-dirs=2 -np -nH -A'*2.1.0-2*' -r \ http://etr-usa.com/cygwin64/expat/ Oh, it's one of *those*. My more recent RFUs include -A'*.hint' in the command. The *.hint files are all there on the server, if you want to re-pull them.
Re: [RFC] cygport: PKG_OBSOLETES
On 7/25/2013 20:31, Yaakov (Cygwin/X) wrote: On 2013-07-25 14:50, Warren Young wrote: I'll wait for this PKG_OBSOLETES feature to ship in Cygport, and be a guinea pig for it. It's in git master already. Cool. I will try to make use of this feature before your next release, but don't hold it waiting on me. I've run out of time to do Cygwin packaging today, and may not have time again until next week.
Re: [RFC] cygport: PKG_OBSOLETES
On 7/23/2013 13:11, Yaakov (Cygwin/X) wrote:
But libexpat1-devel is a BAD choice of name,
You're only having a problem with -devel, right, not the library package
proper?
Does this .cygport file solve the problem?
DESCRIPTION=Expat XML parser library
HOMEPAGE=http://expat.sourceforge.net/;
SRC_URI=mirror://sourceforge/${PN}/${P}.tar.gz
abi=1
PKG_NAMES=${PN} lib${PN}${abi} lib${PN}-devel
PKG_HINTS=setup lib${abi} devel
PKG_CONTENTS[0]='usr/bin/*.exe usr/share/'
PKG_CONTENTS[1]=usr/bin/*-${abi}.dll
PKG_CONTENTS[2]='usr/include/ usr/lib/'
CYGCONF_ARGS=--enable-static
DIFF_EXCLUDES=expat_config.h.in
HTMLDOCS=doc/*.png doc/*.html doc/*.css
The only change from the one I used to build the -2 package is that the
PKG_NAMES line used to be:
PKG_NAMES=${PN} lib${PN}${abi} lib${PN}${abi}-devel
It's probably best to just rename this stuff in the repo. The last
release of Expat was 6 years ago, and I have no information that leads
me to expect another release soon. If there were an imminent release
due, I'd say hold off, and let me roll the change into that version.
Anyway, I've changed my local .cygport file as above, in case I ever
have to use it again. :)
Re: [RFC] cygport: PKG_OBSOLETES
On Jul 24 03:52, Warren Young wrote:
On 7/23/2013 13:11, Yaakov (Cygwin/X) wrote:
But libexpat1-devel is a BAD choice of name,
You're only having a problem with -devel, right, not the library
package proper?
Does this .cygport file solve the problem?
DESCRIPTION=Expat XML parser library
HOMEPAGE=http://expat.sourceforge.net/;
SRC_URI=mirror://sourceforge/${PN}/${P}.tar.gz
abi=1
PKG_NAMES=${PN} lib${PN}${abi} lib${PN}-devel
PKG_HINTS=setup lib${abi} devel
PKG_CONTENTS[0]='usr/bin/*.exe usr/share/'
PKG_CONTENTS[1]=usr/bin/*-${abi}.dll
PKG_CONTENTS[2]='usr/include/ usr/lib/'
CYGCONF_ARGS=--enable-static
DIFF_EXCLUDES=expat_config.h.in
HTMLDOCS=doc/*.png doc/*.html doc/*.css
The only change from the one I used to build the -2 package is that
the PKG_NAMES line used to be:
PKG_NAMES=${PN} lib${PN}${abi} lib${PN}${abi}-devel
It's probably best to just rename this stuff in the repo. The last
release of Expat was 6 years ago, and I have no information that
leads me to expect another release soon. If there were an imminent
release due, I'd say hold off, and let me roll the change into that
version.
Anyway, I've changed my local .cygport file as above, in case I ever
have to use it again. :)
The problem I see is that we have 16 packages in the 32 bit distro
requiring libexpat1-devel, 2 packages in the 64 bit distro, and 8
packages in the 64 bit distro requiring libexpat-devel.
Regardless of libexpat1-devel supposedly being a bad choice of names,
from the global distro perspective, it would be much easier to remove
the libexpat-devel package from the 64 bit distro and go over the hint
files manually for now.
Otherwise you would have to introduce a new 32 bit package and
get all maintainers to change their dependencies accordingly for the
next package.
Just a thought...
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
Re: [RFC] cygport: PKG_OBSOLETES
On 7/24/2013 04:06, Corinna Vinschen wrote: Regardless of libexpat1-devel supposedly being a bad choice of names, from the global distro perspective, it would be much easier to remove the libexpat-devel package from the 64 bit distro and go over the hint files manually for now. Doesn't the problem fix itself for those using Cygport's .hint file generation? For those not using this feature, it would be a gentle clue why it's a good idea. You'd have to fake a -3 package set, with libexpat-devel-3 set to obsolete libexpat1-devel-2, so that package developers would automatically get new packages on their next Cygwin update.
Re: [RFC] cygport: PKG_OBSOLETES
On Jul 24 05:12, Warren Young wrote: On 7/24/2013 04:06, Corinna Vinschen wrote: Regardless of libexpat1-devel supposedly being a bad choice of names, from the global distro perspective, it would be much easier to remove the libexpat-devel package from the 64 bit distro and go over the hint files manually for now. Doesn't the problem fix itself for those using Cygport's .hint file generation? For those not using this feature, it would be a gentle clue why it's a good idea. You'd have to fake a -3 package set, with libexpat-devel-3 set to obsolete libexpat1-devel-2, so that package developers would automatically get new packages on their next Cygwin update. If you're willing to do that for 32 and 64 bit, ok. As soon as you do that, we should still change the affected .hint files manually on sware to get the right deps for new installs. Just give the word. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [RFC] cygport: PKG_OBSOLETES
On 7/24/2013 05:41, Corinna Vinschen wrote: On Jul 24 05:12, Warren Young wrote: You'd have to fake a -3 package set, with libexpat-devel-3 set to obsolete libexpat1-devel-2, so that package developers would automatically get new packages on their next Cygwin update. If you're willing to do that for 32 and 64 bit, ok. I don't see what you need from me. Can't you just copy *-2* to *-3* except for libexpat1-devel*-2* which becomes libexpat-devel*-3*, then manually change all the *.hint files referencing libexpat1-devel? I mean, if I rebuild my packages here using the new .cygport file I posted, aren't I going to get exactly the same output tarballs as before, just with different names?
Re: [RFC] cygport: PKG_OBSOLETES
On Jul 23 00:02, Yaakov (Cygwin/X) wrote: I wanted to get feedback from those using cygport regarding a possible new feature: PKG_OBSOLETES. This is best explained with an example, so let's say I had the following: NAME=libfoo ... PKG_NAMES=libfoo1 libfoo-bin libfoo-devel libfoo1_CONTENTS=usr/bin/cygfoo-1.dll libfoo_bin_CONTENTS=etc/ usr/bin/*.exe usr/share/doc/ usr/share/man/man[15] libfoo_devel_CONTENTS=usr/include/ usr/lib/ usr/share/man/man3/ It then becomes apparent that libfoo-bin is a really bad name for a package, because people looking for the executables aren't finding an obvious match in the package list. Also, libfoo1 really needs those configuration files, so I decide to add a libfoo-common package, and rename libfoo-bin to foobar. Right now, I could do the following: PKG_NAMES=libfoo1 libfoo-bin libfoo-common libfoo-devel foobar libfoo1_REQUIRES=libfoo-common libfoo1_CONTENTS=usr/bin/cygfoo-1.dll libfoo_common_CONTENTS=etc/ usr/share/doc/ usr/share/man/man5/ libfoo_bin_CATEGORY=_obsolete libfoo_bin_REQUIRES=foobar libfoo_bin_SUMMARY=Obsolete package libfoo_bin_CONTENTS= # empty libfoo_devel_CONTENTS=usr/include/ usr/lib/ usr/share/man/man3/ foobar_CONTENTS=usr/bin/*.exe usr/share/man/man1/ While that works, that's a lot of lines to handle an empty package. What PKG_OBSOLETES could do is make that much simpler: PKG_NAMES=libfoo1 libfoo-common libfoo-devel foobar libfoo1_REQUIRES=libfoo-common libfoo1_CONTENTS=usr/bin/cygfoo-1.dll libfoo_common_CONTENTS=etc/ usr/share/doc/ usr/share/man/man5/ libfoo_devel_CONTENTS=usr/include/ usr/lib/ usr/share/man/man3/ foobar_OBSOLETES=libfoo-bin foobar_CONTENTS=usr/bin/*.exe usr/share/man/man1/ The attached patch is what I'm working with at the moment. Thoughts? Looks good to me. Btw., did you create the 64 bit expat packages or did Warren? The history isn't visible, unfortunately. I'd like to see a solution for the libexpat-devel vs/ libexpat1-devel problem. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [RFC] cygport: PKG_OBSOLETES
On 2013-07-23 04:06, Corinna Vinschen wrote: On Jul 23 00:02, Yaakov (Cygwin/X) wrote: I wanted to get feedback from those using cygport regarding a possible new feature: PKG_OBSOLETES. Looks good to me. Thanks for the feedback. Btw., did you create the 64 bit expat packages or did Warren? The history isn't visible, unfortunately. I'd like to see a solution for the libexpat-devel vs/ libexpat1-devel problem. I built 2.1.0-1 during the bootstrap stage; 2.1.0-2 must be Warren's. But libexpat1-devel is a BAD choice of name, as it would collide with a future -devel corresponding to libexpat2 should the ABI change again. I wish we had some policies in this regard, but IMO the proper fix is revert this to libexpat-devel. Yaakov
Re: [RFC] cygport: PKG_OBSOLETES
Warren, Ping? On Jul 23 14:11, Yaakov (Cygwin/X) wrote: On 2013-07-23 04:06, Corinna Vinschen wrote: On Jul 23 00:02, Yaakov (Cygwin/X) wrote: [...] Btw., did you create the 64 bit expat packages or did Warren? The history isn't visible, unfortunately. I'd like to see a solution for the libexpat-devel vs/ libexpat1-devel problem. I built 2.1.0-1 during the bootstrap stage; 2.1.0-2 must be Warren's. But libexpat1-devel is a BAD choice of name, as it would collide with a future -devel corresponding to libexpat2 should the ABI change again. I wish we had some policies in this regard, but IMO the proper fix is revert this to libexpat-devel. See also http://cygwin.com/ml/cygwin-apps/2013-07/msg00213.html and followup. We need to get rid of either the libexpat-devel dependencies or the libexpat1-devel dependencies. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [RFC] cygport: PKG_OBSOLETES
Yaakov (Cygwin/X) writes: I wanted to get feedback from those using cygport regarding a possible new feature: PKG_OBSOLETES. This is best explained with an example, so let's say I had the following: [..] The attached patch is what I'm working with at the moment. Thoughts? Looks good to me. Could there be some provision to obsolete a package residing in a different subtree? Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [RFC] cygport: PKG_OBSOLETES
On 2013-07-23 14:39, Achim Gratz wrote: Yaakov (Cygwin/X) writes: I wanted to get feedback from those using cygport regarding a possible new feature: PKG_OBSOLETES. This is best explained with an example, so let's say I had the following: [..] The attached patch is what I'm working with at the moment. Thoughts? Looks good to me. Could there be some provision to obsolete a package residing in a different subtree? You could still use PKG_OBSOLETES, but relocating or removing the obsoleted package would still have to be done by the uploader. The only way that could be automated is if subpackages were to be placed alongside their main packages instead of underneath them. While that may be worth considering when we get to the point of having a buildbot, it isn't in the scope of this patch. Yaakov
