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

Yaakov (Cygwin/X) yselkowitz@users.sourceforge.net
Tue Feb 12 10:19:00 GMT 2013

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.


More information about the Cygwin-apps mailing list