This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [PATCH] setup -e, --separate-src-dirs option
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