[prev in list] [next in list] [prev in thread] [next in thread] 

List:       crux
Subject:    Re: Do we need a new package utility?
From:       Johannes Winkelmann <jw () tks6 ! net>
Date:       2002-06-21 9:26:04
[Download RAW message or body]

Hi Florian

On Fri, Jun 21, 2002 at 10:33:34 +0200, Florian Weber wrote:
[...]
> If I understand you correctly Johannes, you have a collection of directories 
> where ports will be looked up:
>   port_roots = ( /usr/ports, /home/me/ports, /even/more/ports )
> You then walk through all those directories and collect the port names (among 
> other things), ignoring their respective locations.
rather like 
prt_dirs = []
prt_dirs.append( '/usr/ports/base' )
prt_dirs.append( '/usr/ports/opt' )
prt_dirs.append( '/usr/ports/contrib' )
prt_dirs.append( '/usr/ports/unofficial' )

where of course this is the program's syntax, not the user's :-)

> Now the change:
> (this is a bit contrary to your idea, but please hear me through) 
sure I like to hear comments!

> [...] Instead of 
> using only the port name, use the port's name relative to it's root
>   /usr/ports/base/bash --> base/bash
>   /home/me/ports/foo --> foo
>   /even/more/ports/foo --> foo
> 
> Rules:
> - - If a qualified port name (e.g. base/bash) is given, only ports
> with exactly this name match.
Why would you like this qualification? I think that if a user
has his/her own port of bash, why should he/she not want to use that?
And why should the packager (writing the Pkgfile) take this decision,
not the user while editing the port roots in /etc/prt-get.conf? 

I think it should be the user's responsibility to use the correct order
of port directories to choose whatever port he/she wants to use.  

Another problem is that if you specify dependecies explicitely, you'll
get an error if something is moved to contrib, or out of contrib. Then
we would have to specify rules when packages are allowed to hardcode
pools (like base/opt/contrib/unofficial). A possible rule would be that
it's only allowed to specify it for base and opt, but then it's much
simpler to just list /usr/ports/base and /usr/ports/opt first in the
ports root list.
IMHO it would not make it simpler but rather harder. 

I fail to see a good example (due to a lack of imagination :-)), as I
only have duplicate ports where I always want to use my modified one and
therefore just place its directory before the other port roots. Do you
have a use case?

> Disadvantages: 
> - - implementation becomes harder (don't know how much)
this is probably not a big deal, really... I think this could be
implemented very easily, so don't use this argument against your idea
;-)

> Advantages:
> - - you can keep your mode of operation :-)
mmmh... can't really see why you couldn't keep the mode of operation
without the explicit qualification of the pool (base/opt/contrib...)

> - - "Pkgfile.local" becomes trivial (I'm still very much in favour of
> this, as you can see)
It's trivial without the specification, just use pkgclose.sh (shameless
plug) in /usr/ports/local and specify /usr/ports/local before all the
other ports directories :-)
Also note that in my case, those ports I modify locally are usually
those I use anyway, therefore they are already installed and not
relevant for prt-get (or only if we take package versions into account,
but I fear this will lead to a new dimension of dependecy hell: packageA
requires a later version of libraryB, but packageC which is already
installed requires libraryB in excatly this version. There is no way to
find out what packages is require what others, and as I like it that
way (no dependencies stored), I don't intend to implement such things
right now. All I want is a tool to _install_ a suite of applications - 
or package cluster as called by maol - the easy way, with one command. I
don't want to extend crux to support dependencies!) 


Anyway, from the developer's point of view your idea is an extention to
mine, so I'll proceed as planned (ok, there is no actual plan :-)) and
we can then incorporate it if you still need it, ok ?

Thanks for you input!
Regards, Johannes
-- 
Johannes Winkelmann         mailto:jw@tks6.net
Trondheim, Norway           http://jw.tks6.net 

[prev in list] [next in list] [prev in thread] [next in thread]