Ports management tools in the base (Was: Re: cvs commit: www/en/projects/ideas ideas.xml)

[Doug Barton]

Pav Lucistnik wrote:
> Alexander Leidinger píše v po 19. 03. 2007 v 12:51 +0100:
>> Quoting Pav Lucistnik <pav at FreeBSD.org> (from Sun, 18 Mar 2007  
>> 16:38:50 +0000 (UTC)):
>>
>>> pav         2007-03-18 16:38:50 UTC
>>>
>>>   FreeBSD doc repository
>>>
>>>   Modified files:
>>>     en/projects/ideas    ideas.xml
>>>   Log:
>>>   Add four new ports related entries:
>>>   4) portupgrade in base thing
>> Isn't portmaster something which would fit here already? I didn't  
>> looked at it, I just judge from what I did read in the lists.
> 
> Possibly. But it still isn't either finished or in base.

This thread started with the ideas page entry here:
http://www.freebsd.org/projects/ideas/index.html#p-ports-upgrade

In response to Pav's suggestion above, I haven't put portmaster in the 
base for a few reasons, the most important one of which is that my 
feeling is that the only ports related tool that should be in the base 
is pkg_add. I think that the rest of them should be ports themselves, 
which not only is cleaner architecturally, but also has a lot of 
advantages when it comes to things like adding new features to them. 
Another reason, for whatever it's worth, is that up till now no one 
has suggested that it go into the base (which is fine with me).

As for it not being finished, is any software project ever really 
finished? :) I'm pretty close to the end of the list of features that 
I was ever interested in implementing, and I've added almost every 
feature that users have asked for (with the notable exception of 
installing packages). So I would classify the project as "mature," and 
if there is clamor for it to go into the base, I would be willing to 
do so.

That said, I would have a great deal of concern over the idea of 
having something that implemented a lot of portupgrade's features in 
the base. I say this with all due respect to sem, and everyone else 
who's been involved in the development of portupgrade. I think it's a 
fine tool, and I am all for the idea of people developing and using 
tools that meet their interest and needs. I have never viewed 
portmaster as a competitor of portupgrade, and indeed I've said many 
times that it's not even on my radar to be working on a "portupgrade 
replacement." My concern is related to the idea of having such a tool 
in the base dramatically expanding the complexity of the ports 
infrastructure beyond what it is already. Personally I've noticed a 
lot of additional complexity that has been added since portupgrade 
first starting becoming popular, and my gut feeling is that a lot of 
things are done with the rationale "oh, they can just use portupgrade 
to fix things up after I'm done." If we want to re-architect the ports 
system so that it _requires_ some sort of database other than 
/var/db/pkg, fine. Let's have that discussion (which I realize would 
be the nightmare bikeshed from hell), but let's not back into it by 
adding a portupgrade-like tool to the base which becomes mandatory 
inch by inch.

As for the requirements in the ideas page ...

The required functionality is:
     * fixing @pkgdep records in +CONTENTS file
     * fixing +REQUIRED_BY records

Portmaster already does these two, and that part of the code is very 
mature since it's one of the first features I wanted for myself when I 
started developing it.

     * storing old copies of shared libraries after shmajor number 
change in /usr/local/lib/compat/pkg

Portmaster doesn't do this currently. I have mixed feelings about 
whether this is even a good idea or not. I'd be happy to elaborate on 
why if anyone cares.

     * upwards and downwards recursive modes

If I understand you correctly, what portmaster does currently when 
building a port (a depth-first traversal of the dependency tree) would 
be considered downwardly recursive, and the -r function (ala 
portupgrade's) might be considered upwardly recursive, but I'm not 
100% sure I'm right here. :)

I think one meta-requirement that is implied on the web page but not 
stated is that the tool not rely on any features that don't already 
exist in the base. Since portmaster is written in /bin/sh, and doesn't 
rely on any databases to do its work, it meets that requirement.

Now having said all that, I still want to reiterate my point that I 
feel the conversation we _should_ be having is moving all the 
ports/package management tools other than pkg_add into the ports tree, 
but if people are determined to put "a port management tool" into the 
base, then yes, I'd like portmaster to be considered for that role.

Doug

-- 

     This .signature sanitized for your protection