Re: gbs patch (prep/patch)
On Sat, Mar 27, 2004 at 03:08:37PM -0500, Daniel Reed wrote: On 2004-03-27T21:02+0100, Marcel Telka wrote: ) * templates/generic-build-script (prep): Apply patch only if it is ) available. I believe the .patch is required, even if it is empty. (I am distributing a 0-byte .patch with naim, at least.) http://sources.redhat.com/ml/cygwin-apps/2003-01/msg00248.html Regards. -- +---+ | Marcel Telka e-mail: [EMAIL PROTECTED] | |homepage: http://telka.sk/ | |jabber: [EMAIL PROTECTED] | +---+
gbs patch (install/preremove)
Hi.
Attached is a patch for preremove.sh support.
ChangeLog entry:
2004-03-28 Marcel Telka [EMAIL PROTECTED]
* templates/generic-build-script (install): Add support for preremove
script.
--
+---+
| Marcel Telka e-mail: [EMAIL PROTECTED] |
|homepage: http://telka.sk/ |
|jabber: [EMAIL PROTECTED] |
+---+
Index: generic-build-script
===
RCS file: /cvs/cygwin-apps/packaging/templates/generic-build-script,v
retrieving revision 1.20
diff -u -p -r1.20 generic-build-script
--- generic-build-script18 Mar 2004 23:00:35 - 1.20
+++ generic-build-script28 Mar 2004 08:30:29 -
@@ -214,6 +214,13 @@ install() {
fi \
/usr/bin/install -m 755 ${srcdir}/CYGWIN-PATCHES/postinstall.sh \
${instdir}${sysconfdir}/postinstall/${PKG}.sh ; \
+ fi \
+ if [ -f ${srcdir}/CYGWIN-PATCHES/preremove.sh ] ; then \
+if [ ! -d ${instdir}${sysconfdir}/preremove ]; then \
+ mkdir -p ${instdir}${sysconfdir}/preremove ; \
+fi \
+/usr/bin/install -m 755 ${srcdir}/CYGWIN-PATCHES/preremove.sh \
+ ${instdir}${sysconfdir}/preremove/${PKG}.sh ; \
fi )
}
strip() {
On forming a SC [was Re: ITP moratorium still in effect?]
cgf wrote: I'd like to explore new methods for getting packages into the distribution, however. Possibly we need a gdb packages steering committee which decides on these things. It could have rules like a package needs a simple majority vote to be a candidate for inclusion. I'd envision seven people on the committee. I have names in mind but the only two definites are really Corinna and me, both of whom would also have veto power. I'd also like to see a formal justification for why a package should be included, remembering that we have a software web page at cygwin.com which can be used to advertise packages that aren't quite up to snuff for the cygwin release. I think we have accepted a couple of packages here which really only deserve to be advertised on the web site. Chris, I'd really like to object to this SC idea, as most of us *have* exercised restraint while a select few have not. Why should the responsible maintainers be punished for someone's binge ITP'ing? I think we should keep it the way it is, perhaps with a little more of you laying the smack-down on anyone who is abusing it. I would respect a veto from you, Corinna, or Chuck, but the voting should still be left to the existing maintainers. After seeing what a steering committee has done to gcc, I'd be very hesitant to subject Cygwin to one. Please don't turn Cygwin decisions into political ones. Here's one idea to limit the binge ITP's: No more than 1 ITP per month unless approved by either you or Corinna. Another approach might be to ask: Do the Linux vendors support it?. Obviously this won't apply to strictly-windows applications. However, it is useful in that we are attempting to provide a unix/linux-like environment for Windows. If we are going to use any benchmark, this should be it. I'll end with some personal observations and opinions. I've been a RHL user since the 3.0.3 days, and I've seen the distro go from a small collection of packages to many hundreds of packages. Before that, I remember a time when an entire Slackware distribution fit on 20 floppies. Thus, I perceive our problems as being growing pains. I think understanding how the linux vendors handled these growing pains would be fruitful in how we approach this problem. I know some might not want to hear it, but if setup.exe can't handle the current load or scale in a sane manner, perhaps the problem lies with setup.exe itself? Look, setup.exe has served its purpose well, but now Windows comes with a feature-rich installer API. The last time I checked, this API is available for all versions of Windows since 95. Didn't someone broach the subject of possibly looking into NSIS installer (which, if I'm not mistaken, is a front-end for this API)? Aside from being more aesthetically pleasing, there are some features NSIS has which are quite nice and would mesh well with some of the extended needs now handled by post-install scripts. Choice is what it comes down to, and IMHO it should be the installer who needs to responsible for selecting the packages which best fit his/her needs. I'm sick and tired of seeing things being dumbed down for the benefit of the clueless at the expense of the power-user, and I know I'm not alone. Cheers, Nicholas
Re: On forming a SC [was Re: ITP moratorium still in effect?]
On Sun, Mar 28, 2004 at 04:02:55PM -0500, Nicholas Wourms wrote: cgf wrote: I'd like to explore new methods for getting packages into the distribution, however. Possibly we need a gdb packages steering committee which decides on these things. It could have rules like a package needs a simple majority vote to be a candidate for inclusion. I'd envision seven people on the committee. I have names in mind but the only two definites are really Corinna and me, both of whom would also have veto power. I'd also like to see a formal justification for why a package should be included, remembering that we have a software web page at cygwin.com which can be used to advertise packages that aren't quite up to snuff for the cygwin release. I think we have accepted a couple of packages here which really only deserve to be advertised on the web site. I'd really like to object to this SC idea, as most of us *have* exercised restraint while a select few have not. Why should the responsible maintainers be punished for someone's binge ITP'ing? I think we should keep it the way it is, perhaps with a little more of you laying the smack-down on anyone who is abusing it. I would respect a veto from you, Corinna, or Chuck, but the voting should still be left to the existing maintainers. After seeing what a steering committee has done to gcc, I'd be very hesitant to subject Cygwin to one. I guess we have differing views on how the steering committee affected gcc but this is really very different from the gcc (or gdb) steering committee. In general, I think they do a good job. However, just because I used a similar term to describe this doesn't mean that it will be exactly like gcc's steering committee. I'm coming to feel that their should be a higher bar for package entry into the release and don't think that any old package maintainer should get an equal vote in the process. Here's one idea to limit the binge ITP's: No more than 1 ITP per month unless approved by either you or Corinna. I can't speak for Corinna, but I would rather *not* have to be the bad guy or a single (double?) point of contact. I would rather have more community involvement. I'm already drowning in being the focal point for most cygwin bugs with help from only two other developers. I don't want to invent new things for me or Corinna to do, especially when there is no requirement for in-depth cygwin knowledge. Setting up a council or committee to approve or disprove apps means that the load is shared and there theoretically a consistent way for packages to be included. Another approach might be to ask: Do the Linux vendors support it?. That is exactly an idea that I was going to propose. I was waiting to see where the discussion was going first. I was going to use actually veto ac-archive on this basis but then noticed that when I typed: up2date ac-archive ac-archive got pulled into my fedora-based system. So vetoing ac-archive because for this reason wouldn't work. However, even with this rule, there is still a need for someone(s) to rule on the edge cases. I know some might not want to hear it, but if setup.exe can't handle the current load or scale in a sane manner, perhaps the problem lies with setup.exe itself? This was part of my motivation for asking if setup.exe development was stalled. I think that we are reaching a point where some innovation (and maybe a radical GUI redesign) is needed. Didn't someone broach the subject of possibly looking into NSIS installer (which, if I'm not mistaken, is a front-end for this API)? Yes, someone did. I have no problem with moving to a new installer interface but, given the current level of development, I don't see who's going to do the work. If we don't have a volunteer available to do the work of adapting NSIS but we do have volunteers available to keep setup.exe working then it's really a moot point. I'm sick and tired of seeing things being dumbed down for the benefit of the clueless at the expense of the power-user, and I know I'm not alone. I've always felt like this, actually. The first version of the installer was just a command-line version. I don't think that the current setup.exe is dumbed down. It just isn't really feature-rich. cgf
[Cron cgf cd /sourceware/ftp/anonftp/pub/cygwin; /sourceware/infra/bin/cygwin/upset -C -u setup.ini; /usr/local/bin/upx -q -q -q setup.exe || exit 0]
- Forwarded message from Cron Daemon - From: (Cron Daemon) To: cgf Subject: Cron cd /sourceware/ftp/anonftp/pub/cygwin; /sourceware/infra/bin/cygwin/upset -C -u setup.ini; /usr/local/bin/upx -q -q -q setup.exe || exit 0 Date: 28 Mar 2004 22:20:10 - upset: *** warning package XFree86-html refers to non-existent external-source: XFree86-man - End forwarded message -
Re: [Cron cgf cd /sourceware/ftp/anonftp/pub/cygwin; /sourceware/infra/bin/cygwin/upset -C -u setup.ini; /usr/local/bin/upx -q -q -q setup.exe || exit 0]
Oops. Instead of deleting the old -8 package I deleted the new -9 package. That left -8 without a matching -8 man-src package. Fixed now. Harld Christopher Faylor wrote: - Forwarded message from Cron Daemon - From: (Cron Daemon) To: cgf Subject: Cron cd /sourceware/ftp/anonftp/pub/cygwin; /sourceware/infra/bin/cygwin/upset -C -u setup.ini; /usr/local/bin/upx -q -q -q setup.exe || exit 0 Date: 28 Mar 2004 22:20:10 - upset: *** warning package XFree86-html refers to non-existent external-source: XFree86-man - End forwarded message -
Re: On forming a SC [was Re: ITP moratorium still in effect?]
Yes, someone did. I have no problem with moving to a new installer interface but, given the current level of development, I don't see who's going to do the work. If we don't have a volunteer available to do the work of adapting NSIS but we do have volunteers available to keep setup.exe working then it's really a moot point. Has moving to one of the existing linux packaging systems been considered? This would I think require changing cygwin so first you download a minimum package that just includes cygwin, the installer, and the basic utilties and then we used an existing packaging system. I'm sure this has been suggested before, but is it considered bad because it's not windowsy enough, would require too large a switch-over, or just because no-one is willing to work on it? I ask mainly because I have tried delving into setup.exe a couple of times and have had serious trouble working my way around the code. It seems if cygwin's aim is to produce a unix-type system on windows, surely it would seem sensible to use a unix-type installation system? Chris
Re: On forming a SC [was Re: ITP moratorium still in effect?]
--- chris jefferson [EMAIL PROTECTED] wrote: Yes, someone did. I have no problem with moving to a new installer Has moving to one of the existing linux packaging systems been considered? This would I think require changing cygwin so first you download a minimum package that just includes cygwin, the installer, and the basic utilties and then we used an existing packaging system. I'm sure this has been suggested before, but is it considered bad because it's not windowsy enough, would require too large a switch-over, or just because no-one is willing to work on it? One of the main problems is the assumptions a linux packaging system makes, for example that it can replace in-use executables. At a minimum it would need to be patched to warn about rebooting the way setup.exe does (rpm and dpkg are already available for cygwin, but not recommended for this reason). The biggest problem from a chicken-and-egg perspective is of course cygwin1.dll itself. __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html
