Pierre Pronchery <khorben%defora.org@localhost> writes: > Hi Greg, tech-pkg@, > > [this is also going to tech-pkg@, in spite of the header missing; this > time because my mail client failed to send this message to you due to a > temporary local connectivity issue] > > On 12/11/2017 15:13, Greg Troxel wrote: >> Pierre Pronchery <khorben%defora.org@localhost> writes: >>> Please note this is not bumping anything nor updating references to >>> cups-base's buildlink3.mk, with an exception for cups-filters where it >>> would create a circular dependency otherwise. Let me know if it should >>> be done right away though. >> >> I don't quite follow. If you want to make this change, then there needs >> to be a working cups-base/buildlink3.mk file that refers to cups-base, > > From what I can tell, there is a working cups-base/buildlink3.mk. I couldn't tell that from what you sent :-) But patches for moves are messy, and all that matters is what gets committed. The cups-base/buildlink3.mk file should cause a dependency on cups-base, and it looks like it was still cups. >> and all the things that currently include cups/buildink3 need to be >> changed to refer to cups-base/buildlink3 instead. Basically, after the > > Actually, not necessarily. In practice, now they only depend on > cups-base; however cups/buildlink3.mk also depends on cups-base, so not > only it builds, but it also makes sure the resulting setup is actually > functional. cups will be a metapackage and we generally do not have bl3 for them. > I understand however that some users do not care about a functional > cups, and therefore do not want the extra few megabytes of cups-filters > installed. As I wrote earlier, I am about to update these links to > cups-base and bump revisions accordingly. Indeed, that is a big point. Often packages depend on cups so that the people who use cups can have it work, but it is bloat for those who do not. Ideally the cups support for these would be in modules and could be in a separate package (to avoid bloat, and because there are a fair number of people who really dislike cups). And, in this case, even if people need cups to work, then if the depending package only uses [qinterfaces from cups-base, that's all that should be bl3'd in. We have had other cases (that I can't remember right now) where there is a bl3 dependency for a feature, but you have to install some other package to use it. It was not entirely clear to me that you intended to repoint the bl3 includes of the depending packages. >> change, everything has to be consistent and all the things that depend >> on cups have to build ok. [...] > > You are right, I did not build every dependency of cups on every > platform, every architecture, every version of the platform and > architecture, with every compiler available, with and without cwrappers, > and every possible combination of options available. But I tested that > the new layout is consistent and functional. If you find something that > breaks, let me know and I will try to help fix it. Please stop bringing up ridiculous strawmen. I got the impression that you had not built any of the dependencies at all (and didn't intend to change their bl3 include ilnes). When you change something, you have a responsibility to avoid breakage. The greater the scope of change and the higher the likelihood of breakage, the more testing is needed. Obviously testing every possible commbination as you list is not reasonable. But not testing at all is also unreasonable, and not how we do things. If you changed all of the dependencies in a way that you think will work, and built say 3 of them on one system, that would be a good balance of effort and care. >> I also don't follow the patches. You would be basically reimporting >> cups as cups-base, changing the name, and basically removing the current >> print/cups adding in its place a meta-package (we don't always put those >> in meta-packages/, if they are smallish like this, so that's fine). > > That's exactly right. I do not want to move print/cups to a meta-package > because it would then effectively be renamed - which is heavily > discouraged. I think this allows for a perfectly smooth transition > instead, transparent to the user. > In fact it reproduces prior art in pkgsrc (eg devel/git and > devel/git-base), which I used as inspiration directly. Yes, I was intending to agree, but your message about what you were doing was not 100% clear.
Attachment:
signature.asc
Description: PGP signature