This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [PATCH] setup -e, --separate-src-dirs option
On Dec 15 13:10, Christopher Faylor wrote:
> On Thu, Dec 15, 2011 at 07:38:14AM +0100, Christian Franke wrote:
> >Christopher Faylor wrote:
> >> On Wed, Dec 14, 2011 at 10:16:40PM +0100, Christian Franke wrote:
> >>> Many -src packages install files in /usr/src which have no
> >>> PACKAGE[-VERSION] prefix or substring in file name. This makes it
> >>> difficult to maintain or cleanup larger /usr/src directories.
> >>>
> >>> The attached experimental patch for setup.exe adds option -e,
> >>> --separate-src-dirs. If specified, each PACKAGE-VERSION-src.tar.bz2 is
> >>> installed below /usr/src/PACKAGE-VERSION instead.
> >> If this is really desirable behavior then shouldn't we ask package
> >> maintainers to fix their packages? I don't see why setup.exe should
> >> have to know about this.
> >>
> >
> >The patch is a pragmatic approach which works with all existing
> >packages. It doesn't break anything existing. It would last long time
> >until all src tarballs would be fixed.
> >
> >It is actually difficult to guess the origin of some source files. For
> >example:
> >
> >/usr/src/0.19-data-auto-imports.patch (from flexdll-0.26-1)
> >/usr/src/blacklist.txt (from ca-cerficates-*)
> >/usr/src/config-rpath.patch (from some gcc-* ?)
>
> That's not difficult. It's trivial to figure out where these files
> came from.
>
> I still don't understand the need for this. If everyone thinks it's
> a good idea than why don't we eschew code bloat and make package
> developers use this technique. Otherwise, unless you inspect the
> source files, you'll be adding a separate layer of directory to
> /usr/src for packages that don't need it.
I don't see a problem with that. I don't think it's the better approach
to wait for all package maintainers to create new source packages. It's
much easier to do it once and for all in setup.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat