Re: pkgsrc-wip packages also suffers from PKGWILDCARD do not catch PKGNAME problem

[Lars Nordlund <lars.nordlund%hem.utfors.se@localhost>]

On Fri, 3 Jun 2005 22:16:27 +0200
Thomas Klausner <thomasklausner%users.sourceforge.net@localhost> wrote:

> On Sun, May 29, 2005 at 09:02:05PM +0200, Lars Nordlund wrote:
> > As I reported on tech-pkg@ the other day about a problem with
> > 'make show-needs-update' because PKGWILDCARD does not catch its
> > corresponding PKGNAME. I have now re-run the test in the wip section
> > and found a bunch of hits.
> 
> Same question as in my tech-pkg reply, which of these fall in the
> category of misnamers (excluding appended version numbers or -devel
> etc)?

There were a few more than in pkgsrc. Unfortunately I do not have a
list ready now.


But changing them will not fix the general issue I have with 
show-needs-update. (Why do I bother with show-needs-update? Well, I need
it for 'make parallel' to work in all corner cases.)


I think we need a mechanism in pkgsrc to handle different development
branches of the same program in a generic way. The current scheme says
that for example xchat 2.4.x is a completeley different program than
xchat 1.8.x, just because they are in different pkgsrc directories
(chat/xchat2 and chat/xchat). This is incorrect. They are both versions
of the same program, xchat, and this fact should IMO _not_ be handled
as if they were two different programs, loosely bound together by the
PKGNAME/PKGWILDCARD variables.

My first thoughts about solving this are in the lines of aligning all
xchat versions into chat/xchat and having an extra structure to mirror
the branching strategy of that project. Perhaps an extra level of
directories where the name of the directories represent the name of the
version major number or HEAD/current/LATEST/snapshot. Using the keyword
'stable' might be unwise since some projects might have several major
versions considered stable. In the top level directory a knob variable
would point out which subdirectory to select for that program. A
mk.conf tunable knob, of course. Allowing several versions of the same
program would be ok if the CONFLICTS variable allows it, just like
today.

Hopefully a change like this will help package dependancies a bit.
Just depend upon 'xchat>=2.0:../../chat/xchat', and the xchat package
itself will work out that chat/xchat/2/ is the directory to do make
install from (or chat/xchat/2-snapshot or chat/xchat/HEAD based upon
the user's preference, branch availability and previously installed
version). Today this magic is spread out throughout pkgsrc in this way:
'xchat>=2.0:../../chat/xchat2'. Every package depending on the latest
stable version of xchat must know that it lives in the xchat2 directory.


Comments? Thoughts?


Best regards
        Lars Nordlund


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
pkgsrc-wip-discuss mailing list
pkgsrc-wip-discuss%lists.sourceforge.net@localhost
https://lists.sourceforge.net/lists/listinfo/pkgsrc-wip-discuss