On Fri, Dec 16, 2011 at 10:59:25AM +0100, Corinna Vinschen wrote: >On Dec 15 14:13, Eric Blake wrote: >> On 12/15/2011 01:59 PM, Christopher Faylor wrote: >> > I think it's lame to have something like, e.g., >> > >> > /usr/src/openssh-5.6p1-2/openssh-5.6p1-2 >> > /usr/src/binutils-2.22.51-1/binutils-2.22.51-1 >> > >> > sitting in my /usr/src. I find that nearly as objectionable as having >> > files littered in /usr/src. > >I don't like /usr/src/binutils-2.22.51-1/binutils-2.22.51-1 either, but >it's much less objectionable than having /usr/src littered with the >content of package files. Especially given the fact that most(?) >packages today are packed using cygport which uses a flat file >structure. And, I never liked the rpm way to put everything into >/usr/src/SOURCES or ~/rpmbuild/SOURCES either. In the end, a useless >duplication of the source dir is easier to live with, IMO.
We're all in violent agreement that putting files directly in /usr/src is bad. This doesn't have to be an either/or situation, though. >> Personally, I think hacking setup.exe is less time-consuming to provide >> the hack, but more compute-intensive, as the work is replicated on every >> machine where setup.exe is installed, as well as delayed implementation, >> as not everyone updates setup.exe right away; while repacking existing >> tarballs has a bigger up-front cost for the person doing the repacking, >> but provides a more efficient and instant downstream effect. That, and >> repacking seems fairly easy to automate. I'm now 75-25 in favor of >> cgf's proposed approach of repacking things and leaving setup.exe alone. > >I think that computing time is negligible. The idea to have the logic >in a single place, setup, is much more convincing to me than to enforce >a specific way to pack source packages. Also, compare a 15 lines patch >against the hassle to change 1800 soyurce packages *and* to enforce a >new package method on all maintainers. No need for misleading vividness. If it was decided to change all of the packages then the immediate impact would be on me. I can easily make this change to all of the packages with a few lines of bash. After that, going forward, package maintainers would need to create proper subdirectories. I do that for my packages and apparently you do for yours too. That *was* the recommended method for creating packages at one point. And, as suggested, I don't see why cygport couldn't do that automatically since the consensus is that it's a good idea. Also, it's a very minor thing but if this patch were adopted then the contents of a source package would not precisely match what shows up at http://cygwin.com/packages/ . There would be no subdirectory displayed there. If it is decided that asking package maintainers to change their behaviors is too big a deal then another alternative would be to make a "package mover" which package uploaders could run which modifies source packages automatically before moving them to the release directory on sourceware. I have also been thinking for a long time that there should be a sanity checker which could be run before installing in ~release. That would eliminate the "upset error" email to cygwin-apps that you, I, or Yaakov has to send when upset finds a problem later. cgf
