Pav Lucistnik wrote:
Alexander Leidinger píše v po 19. 03. 2007 v 12:51 +0100:
Quoting Pav Lucistnik <[EMAIL PROTECTED]> (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
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
