Bug 156857 - [repocopy] split lang/gcc45 in a devel and a stable version
[repocopy] split lang/gcc45 in a devel and a stable version
Status: Closed FIXED
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s)
Latest
Any Any
: Normal Affects Only Me
Assigned To: Gerald Pfeifer
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-07 08:30 UTC by Martin.Birgmeier
Modified: 2011-09-26 02:10 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin.Birgmeier 2011-05-07 08:30:09 UTC
I would appreciate splitting the lang/gcc* ports into stable and development versions. These ports are prerequisites for several other ports and therefore installed without explicit requirement by the user.

The lang/gcc* port maintainer does a very laudable job of always (weekly!) updating these ports to their latest versions. Unfortunately, this leads to repeated rebuilds when running portupgrade or portmaster, which in turn requires a long build time without apparent benefits.

Fix: 

The lang/gcc* ports should be split into stable and development versions.

In my opinion it would be best to use the current names for the stable versions, and to add new -devel ports carrying the continuously updated versions, e.g.

lang/gcc46 for the stable version
lang/gcc46-devel for the continuously updated version

The stable version would then only be upgraded when its micro version changes upstream (e.g., from 4.6.0 to 4.6.1), or when there is a critical fix to apply (thereby increasing the FreeBSD revision).
How-To-Repeat: Run portupgrade or portmaster every day, with one of the lang/gcc* ports installed.
Comment 1 Mark Linimon freebsd_committer 2011-05-10 20:09:26 UTC
Responsible Changed
From-To: freebsd-ports-bugs->gerald

Over to maintainer.
Comment 2 gerald 2011-05-29 03:37:57 UTC
I have started to look into this, but first wanted (needed) to make
a change to this port related to upstream packaging changes.  That's
now in and I am looking into some simplifications, then this will be
next.

For the time being, I believe this kind of split makes most sense
for the "recommended" version of GCC (which is lang/gcc45 at this
point).

Gerald
Comment 3 Gerald Pfeifer freebsd_committer 2011-08-15 21:59:29 UTC
Responsible Changed
From-To: gerald->portmgr

portmgr, I have been pondering about this on and off and came to the 
conclusion that in addition to the various lang/gcc* ports I suggest 
to have one lang/gcc port that is the canonical version of GCC in the 
ports tree. 

This would be what we trigger with USE_FORTRAN=yes right now, that is 
similar lang/gcc45 today and lang/gcc46 in the not too far future,  
based on the current test run Pav has been so kind to take care of 
with two key differences: 
1. lang/gcc would primarily be associated with a release of GCC, 
not weekly snapshots (unless there is a strong reason to deviate), 
2. and thusly would be updated only a few times every year. 

If you agree, would you mind repocopying lang/gcc45 to lang/gcc?
Comment 4 Gerald Pfeifer freebsd_committer 2011-09-18 20:48:30 UTC
State Changed
From-To: open->repocopy

Noting for repocopy by portmgr.  Please repocopy lang/gcc46 
(four-six!) to lang/gcc -- the newer version due to pending 
changes around USE_FORTRAN.
Comment 5 Joe Marcus Clarke freebsd_committer 2011-09-19 09:10:25 UTC
State Changed
From-To: repocopy->open

Repocopy complete. 


Comment 6 Joe Marcus Clarke freebsd_committer 2011-09-19 09:10:25 UTC
Responsible Changed
From-To: portmgr->gerald

Repocopy complete.
Comment 7 dfilter freebsd_committer 2011-09-25 15:58:16 UTC
gerald      2011-09-25 14:58:08 UTC

  FreeBSD ports repository

  Modified files:
    lang/gcc46           Makefile pkg-plist 
  Log:
  Prepare for the inclusion of lang/gcc, which is going to track our
  preferred version of GCC (usually based on a release) starting with
  GCC 4.6.1, and add a proper CONFLICTS.
  
  On the way rename %%GCC_VER%% in pkg-plist to %%GCC_VERSION%% and
  make the Makefile machinery a bit more generic to minimize differences
  between lang/gcc ports based on releases and those based on snapshots.
  
  PR:             156857
  
  Revision  Changes    Path
  1.511     +6 -1      ports/lang/gcc46/Makefile
  1.115     +14 -14    ports/lang/gcc46/pkg-plist
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Comment 8 dfilter freebsd_committer 2011-09-26 01:54:51 UTC
gerald      2011-09-26 00:54:38 UTC

  FreeBSD ports repository

  Modified files:
    lang/gcc             Makefile distinfo pkg-descr pkg-plist 
  Log:
  Welcome the new lang/gcc port!  This shall track our preferred version
  of GCC (usually an upstream release).  It starts out as GCC 4.6.1 and
  is thus in conflict with lang/gcc46 and will move towards later minor
  versions of GCC 4.6 and then on to GCC 4.7.
  
  lang/gcc will provide gcc46, g++46, gfortran46 etc. exactly like
  lang/gcc46 with which it is interchangible.
  
  This is also planned to be in sync with our existing USE_FORTRAN knob
  so that users have the option of using this port, rarely updated, or
  the corresponding lang/gcc46 which follows weekly upstream snapshots.
  
  On the way rename %%GCC_VER%% in pkg-plist to %%GCC_VERSION%% and
  make the Makefile machinery a bit more generic to minimize differences
  between lang/gcc ports based on releases and those based on snapshots.
  
  PR:             156857
  
  Revision  Changes    Path
  1.510     +11 -6     ports/lang/gcc/Makefile
  1.373     +2 -2      ports/lang/gcc/distinfo
  1.19      +5 -0      ports/lang/gcc/pkg-descr
  1.115     +14 -14    ports/lang/gcc/pkg-plist
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Comment 9 Gerald Pfeifer freebsd_committer 2011-09-26 01:59:33 UTC
State Changed
From-To: open->closed

I believe this request has been addressed now with the latest 
changes today.  Thanks for raising this issue and making me look 
into it more from a user perspective!