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
