Doug Barton píše v po 19. 03. 2007 v 17:25 -0700: > 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
> 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.
My point of view is that the essential ports/package functionality
should be contained in the base system in the moment the sysinstall or
make installworld finishes it's job.
I consider smooth upgrading of installed packages a part of essential
functionality.
If you're worried about the version embedded into a release being
imposed on users for next two years, well, there's always possibility to
pull a newer version of portmaster from port and install it on older
systems automatically. It has been done with pkg_install suite in the
past.
> So I would classify the project as "mature,"
Great. I was tracking your development lately, so it's good to hear
that. I should try portmaster again soonish.
> As for the requirements in the ideas page ...
>
> * 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.
I find this a massively desirable feature to have. Defaults to on, can
be turned off. It essentially allows people to upgrade gettext to 0.16.1
and don't worry.
An acompanying utility which would try to
prune /usr/local/lib/compat/pkg, rebuilding binaries that link these old
libs, and ultimately deleting the libs, would be nice. I have something
locally, but it's a gross hack.
> * 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. :)
You understood it 100%.
> 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.
Yes, that's kinda understood that anything in base must be fully
operational with only the resources available in base.
--
Pav Lucistnik <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Canada is a country whose main exports are hockey players and cold fronts.
Our main imports are baseball players and acid rain.
-- Pierre Elliott Trudeau
signature.asc
Description: Toto je digitálně podepsaná část zprávy
