- This patch needs to be tested on pointyhat because there is new Mk/bsd.gstreamer.mk - Splits multimedia/gstreamer-plugins in to a per port per plugin type port. - Utilizes new macro USE_GSTREAMER/WANT_GSTREAMER - each port that used USE_GNOME=gstreamerplugins has been update accordingly to new WANT/USE_GSTREAMER macro
> What is the reason for not wanting it as a separate .mk file? Merging > it into bsd.gnome.mk has no real advantage that I can see. Sure, we > save one inode, but this is decidedly not a good enough reason for > denying a new .mk file. We would still need to touch bsd.port.mk anyway > to teach it about the new USE_GSTREAMER macros. My feeling related to .mk files is to add them for some global stuff, like gnome/kde/java/autotools. Even until now I'm pretty unsure if it was quite wise to commit a new bsd.gcc.mk stuff, since it could also live in bsd.port.mk further. I don't really care about inodes, I just think that expanding Mk/*.mk infrastructure won't improve the quality of the ports, it can only confuse people if they encounter a big bunch of files to handle with. > On the other hand, there are a lot of ports that will be using the new > gstreamer infrastructure, and it will be clearer to porters, and easier > for us (gnome@) to maintain if this was added to a separate .mk file. I suspect these ports are gnome ports, in that case it would be even *better* to merge gstreamer stuff with bsd.gnome.mk.
State Changed From-To: open->closed portmgr doesn't want another .mk file, going to merge bsd.gstreamer.mk in bsd.gnome.mk
> My feeling related to .mk files is to add them for some global > stuff, like gnome/kde/java/autotools. Even until now I'm pretty > unsure if it was quite wise to commit a new bsd.gcc.mk stuff, since > it could also live in bsd.port.mk further. I don't really care > about inodes, I just think that expanding Mk/*.mk infrastructure > won't improve the quality of the ports, it can only confuse people > if they encounter a big bunch of files to handle with. How does it confuse people? In general, "people" don't care about .mk files at all. They just cd to a directory, and type "make install." Porters on the other hand, don't want to have to go weed through all of the GNOME-specific comments and instructions to find the gstreamer stuff they actually care about. Plus, if I'm creating a gstreamer port, I'm more apt to look at bsd.gstreamer.mk file for help than I would be a bsd.gnome.mk file. > > > On the other hand, there are a lot of ports that will be using the new > > gstreamer infrastructure, and it will be clearer to porters, and easier > > for us (gnome@) to maintain if this was added to a separate .mk file. > > I suspect these ports are gnome ports, in that case it would be even > *better* to merge gstreamer stuff with bsd.gnome.mk. KDE is going to start using gstreamer soon from what I understand. Plus, not all of the gstreamer ports are GNOME Desktop or GNOME Fifth Toe ports. Some are not maintained by gnome@ at all.
> How does it confuse people? In general, "people" don't care about .mk > files at all. They just cd to a directory, and type "make install." > Porters on the other hand, don't want to have to go weed through all of > the GNOME-specific comments and instructions to find the gstreamer stuff > they actually care about. Shouldn't be very "expensive" search though. > Plus, if I'm creating a gstreamer port, I'm more apt to look at > bsd.gstreamer.mk file for help than I would be a bsd.gnome.mk > file. According to this we can move soon to: bsd.apache.mk, bsd.xfce.mk, bsd.mozilla.mk, bsd.whateverportIwant.mk and that's why I object here. > > > On the other hand, there are a lot of ports that will be using the new > > > gstreamer infrastructure, and it will be clearer to porters, and easier > > > for us (gnome@) to maintain if this was added to a separate .mk file. > > > > I suspect these ports are gnome ports, in that case it would be even > > *better* to merge gstreamer stuff with bsd.gnome.mk. > > KDE is going to start using gstreamer soon from what I understand. > Plus, not all of the gstreamer ports are GNOME Desktop or GNOME Fifth > Toe ports. Some are not maintained by gnome@ at all. Watching at gstreamers' Makefile I can't find any pitfalls or complicated loops which really require own .mk file.
> Shouldn't be very "expensive" search though. But it could be avoided altogether by making the file named for what it is. > According to this we can move soon to: bsd.apache.mk, bsd.xfce.mk, > bsd.mozilla.mk, bsd.whateverportIwant.mk and that's why I object > here. And why not? I haven't heard a compelling reason why this is such a bad idea. If enough ports exist to warrant a centralized framework, why not do it? It beats cluttering bsd.port.mk. > Watching at gstreamers' Makefile I can't find any pitfalls or > complicated loops which really require own .mk file. Finding the list of supported modules can be complicated enough. What real problems will having an additional .mk file cause?
> Finding the list of supported modules can be complicated enough. What > real problems will having an additional .mk file cause? There is a reason not to use global .mk files, or at least not to expand their amount. The changes in these files require very careful tests, well, you know it, and errors can impact a lot of ports. If changes are critical, maintainers require additional pointyhat runs, hence it costs too much time not only for maintainers, but also for portmgr, to keep .mk files in good shape. According to new releace cycle scheme, we are pushed to increase ports freeze times per year, plus we have portmgr PRs, hence we have time pressure. Do you remember bsd.openssl.mk mess created by dinoex ? Can somebody assure that it won't be repeated in the future ? -Kirill
> According to new releace cycle scheme, we are pushed to increase > ports freeze times per year, plus we have portmgr PRs, hence we have > time pressure. Do you remember bsd.openssl.mk mess created by > dinoex ? Can somebody assure that it won't be repeated in the > future ? Adding an additional .mk file will not cause any more porting messes than appending to an existing one. And even if we did something like PHP used to do by including a bsd.gstreamer.mk in multimedia/gstreamer, that still wouldn't prevent the problem you're describing here. No one can assure you that any change to the ports tree won't cause a circular dependency, broken INDEX, etc. But saying he are going to limit the number of .mk files because something _might_ go wrong is just not right. Global .mk files don't add anymore _reoccurring_ burden to the ports tree than a commit to, say, devel/glib20 (there is definitely a one-time burden of checking the bsd.port.mk hooks).
> Adding an additional .mk file will not cause any more porting messes > than appending to an existing one. And even if we did something like > PHP used to do by including a bsd.gstreamer.mk in multimedia/gstreamer, > that still wouldn't prevent the problem you're describing here. Expanding .mk files also as usual expands amount of USE/WITH/WANT etc stuff, their usage should be also reconsidered IMHO. > No one can assure you that any change to the ports tree won't cause a > circular dependency, broken INDEX, etc. But saying he are going to > limit the number of .mk files because something _might_ go wrong is just > not right. Global .mk files don't add anymore _reoccurring_ burden to > the ports tree than a commit to, say, devel/glib20 (there is definitely > a one-time burden of checking the bsd.port.mk hooks). *shrugs* Okey if nobody else objects, just add it, but I don't really like such kind of solution.
> Expanding .mk files also as usual expands amount of USE/WITH/WANT > etc stuff, their usage should be also reconsidered IMHO. That's a different argument altogether. IMHO limiting such things will invite even more problems since porters would then have to duplicate work that would otherwise be hidden from them. For example, one would have to add the contents of gnomeprefix to every port manually. Doing so can can cause copy and pastos, resulting in more breakage. > *shrugs* Okey if nobody else objects, just add it, but I don't > really like such kind of solution. Fair enough. What say the rest of portmgr? Joe
State Changed From-To: closed->open Reopen with link to "newer" patch http://people.freebsd.org/~ahze/ports-gst.diff.bz2 This patch is in sync with lastest changes to ports tree.
Responsible Changed From-To: freebsd-ports-bugs->portmgr Turn over to portmgr
For the purposes of the audit trail, see also PRs: ports/77839 ports/77877 ports/77879 ports/77881 ports/77884 ports/77886 ports/77887 ports/77889 ports/77890 ports/77892 ports/77894 ports/77897 I won't clutter this PR with the contents, as a consensus appears to have been reached already.
State Changed From-To: open->closed Committed, thanks!