[PATCH 0/2 rebase] Handle CPAN/etc. DLLs in rebaseall
Tue Feb 12 11:02:00 GMT 2013
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 Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
More information about the Cygwin-apps