Bug 77838 - [PATCH] multimedia/gstreamer-plugins -- needs pointyhat testing -- Split plugins in a per port per gstreamer-plugin module.
Summary: [PATCH] multimedia/gstreamer-plugins -- needs pointyhat testing -- Split plug...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Port Management Team
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-21 09:40 UTC by Michael Johnson
Modified: 2005-02-28 21:13 UTC (History)
1 user (show)

See Also:


Attachments
ports.diff.bz2.uu (21.23 KB, text/plain)
2005-02-21 09:40 UTC, Michael Johnson
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Johnson freebsd_committer 2005-02-21 09:40:16 UTC

- 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
Comment 1 krion 2005-02-21 09:41:08 UTC
> 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.
Comment 2 Michael Johnson freebsd_committer 2005-02-21 10:01:46 UTC
State Changed
From-To: open->closed

portmgr doesn't want another .mk file, going to merge bsd.gstreamer.mk in bsd.gnome.mk
Comment 3 Joe Marcus Clarke 2005-02-21 20:40:33 UTC
> 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.
Comment 4 krion 2005-02-21 20:54:30 UTC
> 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.
Comment 5 Joe Marcus Clarke 2005-02-21 21:28:37 UTC
> 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?
Comment 6 krion 2005-02-21 21:49:27 UTC
> 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
Comment 7 Joe Marcus Clarke 2005-02-21 22:44:07 UTC
> 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).
Comment 8 krion 2005-02-21 23:08:09 UTC
> 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.
Comment 9 Joe Marcus Clarke 2005-02-21 23:25:59 UTC
> 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
Comment 10 Michael Johnson freebsd_committer 2005-02-23 07:55:40 UTC
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. 



Comment 11 Michael Johnson freebsd_committer 2005-02-23 07:55:40 UTC
Responsible Changed
From-To: freebsd-ports-bugs->portmgr

Turn over to portmgr
Comment 12 Ceri Davies freebsd_committer 2005-02-23 20:45:36 UTC
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.
Comment 13 Kirill Ponomarev freebsd_committer 2005-02-28 21:13:36 UTC
State Changed
From-To: open->closed

Committed, thanks!