[PATCH 0/2 rebase] Handle CPAN/etc. DLLs in rebaseall

[Corinna Vinschen]

On Feb 12 04:19, Yaakov wrote:
> On Tue, 12 Feb 2013 10:26:00 +0100, Corinna Vinschen wrote:
> > On Feb 12 02:58, Yaakov wrote:
> > > On Tue, 12 Feb 2013 09:18:30 +0100, Corinna Vinschen wrote:
> > > > Yes, the file idea makes sense.  /etc/rebase-extra-dirs?
> > > 
> > > Having a single file which multiple packages are responsible for
> > > editing automatically during postinst/prerm is just adding another
> > > possible (likely?) point of failure.  If you all insist on going this
> > > route, then at least make an /etc/rebase.conf.d directory and
> > > cat(1) the files therein.  But again, IMO this approach is unnecessarily
> > > complicated, as there are only a few well-known CPAN-like systems to be
> > > concerned about, and new ones don't come around very often.
> > 
> > Ah yes, a directory might be the better idea.
> > 
> > I don't actually insist, but the file idea isn't really bad, is it?  It
> > has the merit that you get an extension to rebaseall for free if it
> > suddenly makes sense, without having to create a new rebase package.
> 
> The intention of this patch was to cover DLLs which are commonly and
> expectedly being installed by users outside of the package manager
> because the means to do so is included in packages which we do provide,
> such as with CPAN.  This would effectively merge rebaseall and
> perlrebase/etc. in order that they should actually work and not compete
> with each other (as explained in my aforementioned post), and do so
> easily and immediately without having to wait for each of these packages
> to be rebuilt in order to add the necessary file.
> 
> There are only a handful of such systems, any additions won't be
> "sudden", and then they do arise, likely won't be big enough at first to
> rush the enormous ;-) task of a new rebase release.
> 
> > You don't know the hype script language of 2015 yet :)
> 
> I'm confident that we'll find one reason or another to sneak in a
> rebase release between now and then. :-)
> 
> > Also the directory might be a good idea for users creating their own
> > DLLs.
> 
> Then the conf.d could be in addition to my patch, in which case
> my patch is just avoiding the need for the packages in question to
> state that which we already know.

I'm ok with that, but ultimately it's Jason's call.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat