[PC-BSD Testing] ports tree auto-update

Tigersharke . tigersharke at gmail.com
Wed Dec 14 17:18:56 PST 2011


On Wed, Dec 14, 2011 at 6:41 PM, Arthur <A-Koziol at neiu.edu> wrote:

> **
> On 12/14/2011 5:33 PM, Tigersharke . wrote:
>
>
>
> On Wed, Dec 14, 2011 at 4:13 PM, Sean Cavanaugh <Millenia2000 at hotmail.com>wrote:
>
>>  ‘Portsnap fetch extract’  ??
>>
>>
>>
>> *From:* testing-bounces at lists.pcbsd.org [mailto:
>> testing-bounces at lists.pcbsd.org] *On Behalf Of *Tigersharke .
>> *Sent:* Wednesday, December 14, 2011 4:42 PM
>> *To:* PC-BSD Testing list
>> *Subject:* [PC-BSD Testing] ports tree auto-update
>>
>>
>>
>> Howdy,.,
>>
>> A conversation on IRC lead to this thought..
>>
>> Currently when a new system is installed, the ports tree (and source) are
>> pulled from the install media, and it is unpacked from a tarball.
>>
>> What I propose, is that the above happens as usual, however:  (contingent
>> upon network/repo access)
>>
>>    - at first boot or first login, the system updater does a check on
>>    the ports tree and updates it (*if* the ports tree was added during
>>    install).
>>    - could system source be 'sketched in' and then obtained at first
>>    boot/login?
>>
>> With this arrangement, the ports tree is not stale and its freshness is
>> not so tied to the release date of the media.  Things like EasyPBI
>> (especially once it is available as a PBI itself) will then be able to work
>> on the latest ports.
>>
>> Thanks for your time and interest!
>>
>>
> Of course portsnap fetch extract (and/or update) would work.
>
> However, an assumption with PC-BSD is ease-of-use and general automation
> of tasks.  I was not necessarily suggesting any sort of continual update
> process, though that could be done.  What I meant was that at the least,
> the first login to a fresh install of PC-BSD, would have the most
> up-to-date ports tree.  It may actually use portsnap behind the scenes to
> accomplish this.
> The reasoning was the expectation by the average user that everything
> is/would be current right after install. Many of us are very well aware
> that there is a flood of updates due to freezes around release time.
> Additionally, I foresee an increased use of things such as EasyPBI, which
> necessarily would work best with an up-to-date ports tree.
>
> Actually, now that I've spent more time thinking about it.. it makes a lot
> of sense for those who choose to install the ports tree, that it auto
> updated on a reasonably regular basis. This is only the tree framework, and
> not an update of installed ports in which case there could be issues (as
> reported in /usr/ports/UPDATING).
>
>
>
> <2 Cents>
> Well, I know there are some on this list who are still stuck on dial-up
> for whatever reason and for an automatic ports fetch to run without asking
> would suck what little bandwidth they had. They'd be wondering why the
> connection was so slow not knowing that a background task pulling ports
> tree is running. If such a thing were ever implemented, a simple dialogue
> box asking "Hey, do you want to download the latest ports tree right now?"
> Doing it without asking is probably not the best approach for those
> situations I just described. I don't think some kind of thing that can be
> scheduled (daily, weekly, monthly, etc.) to automate the fetch is such a
> bad idea. It seems like a natural evolution to me but it should have user
> control over schedule and settings to turn it on or off.
> </2 Cents>
>
> Arthur
>

That seems very reasonable. It could be set for automatic during install
and/or have the confirmation as described. It would even be reasonable to
default to such a confirmation depending on limited network connectivity,
meaning that perhaps in such a situation it would always have a
confirmation. It is very easy to forget that there may be those with
limited bandwidth/connectivity but where possible the system should
function appropriately.

Thanks for the comment!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pcbsd.org/pipermail/testing/attachments/20111214/2f6ceb21/attachment.html>


More information about the Testing mailing list