Re: [PATCH] setup -e, --separate-src-dirs option

[Eric Blake <eblake at redhat dot com>]

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.

Agreed.  So right now, some packages use versioned subdirs, others
don't.  Your argument is that it's easier to enforce consistency on the
existing tarballs than it is to make setup.exe have a special case code,
and that new package versions should follow the conventions.

> 
> If this is enforced we can't wait for package maintainers to create new
> source packages.  If they create new source packages with uniquely named
> directories then they will fall prey to the above.
> 
> If everyone thinks this is the way to go then I can change all of the
> source files in ~release and people can change their procedures going
> forward.

If you want to go with the tarball repackaging instead of setup.exe
hack, then let's first fix cygport to generate versioned subdirs (as
that will knock out a large percentage of non-compliant packages).
Conversely, if we hack setup.exe, then the hack has to avoid creating
double-versioned directories, and only insert the versioning if one is
not already present in the existing tarball (the patches proposed to
date have not done that, but it also doesn't seem to hard to further
improve the patch).

I'm fine with either approach (minimal work for me as a packager either
way - either the packaging guidelines become stricter, but I comply the
next time I repackage with the updated cygport, or they stay loose;
meanwhile, before I repackage, the problem is already taken care of on
my behalf, whether by repackaging existing -src tarballs or by hacking
setup.exe, neither of which requires me to repackage any sooner than I'm
ready).  I care more about reaching our end goal - no patch files dumped
in the top-level /usr/src, just one-level versioned directories.

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.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature