Thomas Klausner <wiz%NetBSD.org@localhost> writes: > On Tue, Jun 17, 2014 at 10:30:56PM +0200, Hauke Fath wrote: >> On Tue, 17 Jun 2014 15:20:36 +0200, Thomas Klausner wrote: >> > I've reimported cups-1.5.x as print/cups15, I hope that's sufficient. >> >> Thanks! >> >> I guess the following would fix PR pkg/48889 for now? > ... >> .if !empty(PKG_OPTIONS:Mcups) >> -.include "../../print/cups/buildlink3.mk" >> +.include "../../print/cups15/buildlink3.mk" >> CONFIGURE_ARGS+= --enable-cups >> .else >> CONFIGURE_ARGS+= --disable-cups > > For netatalk22 it's definitely correct. > > I'd also like to hear opinions if for this branch all cups-packages > should depend on cups15, and we switch back to cups after the branch; > or if we should have a general switch for this (i.e., mk/cups.mk which > chooses one of the two, depending on a user-setting). Well, really the problem is that the update to 1.7 happened when it doesn't work well enough, and now we have cups15 which I see as the main/normal version and cups which is the new/flaky version. It seems 1.5 is the version that should be handed to a user who doesn't understand which one they want (or rather, people who are running 1.5 shouldn't get upgraded to 1.7). So I would say that pring/cups should be downgraded to 1.5, and print/cups17 could exist or it could not for the branch and it can be brought back (as cups17) post-branch. But that's not super important, and I can see the argument against churn. Given the current names, I would say everything that depends on cups should depend on print/cups15. Post branch, I think the thing to do is for people that like cups to get the 1.7 package and associated cups-filters packages to the point where they work well enough that they can be recommended for general use. When that happens, however long it takes, then the dependencies can be flipped from print/cups15 to print/cups. THen after long enough to make sure there aren't issues, cups15 can be removed. I don't see any reason to go to the complexity of cups.mk. We're only in this situation because the upgrade happened before the package really worked, and once 1.7 and associated other packages (not clear how many more are needed) are ok, there will be no good reason to stay with 1.5.
Attachment:
pgpKXjltnKVZi.pgp
Description: PGP signature