First of all, please don't cross post.

On Saturday 13 May 2006 10:28, fbsd wrote:
> To all question list readers;
>
> Now with 14576 ports in the collection where do you
> draw the line that its too large to be downloading
> the whole collection when you just use 10 or 20 of them?
> The port collection is growing at a ever increasing rate per month.
> The mass majority of the ports are so special purpose that only a
> very few people have need of them. Sure there are ways to limit
> the categories you select to download, but still the size of
> the most used categories is too large and loaded with ports not
> commonly used by the general user.
>
> So people them use the packages. But the problem with the
> packages is they are not updated every time changes are
> made to the port they were created from. Also packages that
> have dependants like php4/php5 or mysql4/mysql5 are not being
> updated to use the newer versions of those dependants as they come
> out.
>
> I for one think the port/package collection has already grown to
> large to handle in it's present state.
> Users are consuming massive bandwidth to download and it
> consumes a very large chunk of disk space. Saying nothing about
> the wasted resources consumed to back it up repeatedly.
>
> I have gone to using the package version for everything and
> only downloading the ports config files for packages that
> I need to compile from scratch to change some add on function.
> This methodology has worked fine since FreeBSD version 3.0 as
> I used each new release of FreeBSD up to 6.1.
>
> Now in 6.1 there is problems with packages that have not been
> recreated using the new system make file.
> This problem is caused by there being no mandatory requirement on
> the ports maintainers to recreate the packages any time one of the
> dependants change or when changes are made to the canned make
> process
> or when dependants show up as broken. Yes I know what a large task
> this is and that it requires a lot of run time to accomplish.
>
> So my question is how do we users make our needs known
> to the ports maintainer group so that will seriously address
> the problem of the packages being outdated?
>
> Are there other people on this list who are dissatisfied with the
> packages and the problems associated with using packages and ports
> mixed together?
>
> What are your thoughts about requesting the ports group to create
> a new category containing just the ports most commonly used
> including
> their dependents and making this general category the default
> used to download. This would be a much smaller sized download
> containing everything necessary to build the most used ports.
> Many of the dependents are used over and over by many
> different port applications.

This will never work. I doubt if you could find agreement between two users as 
to what to include. We really don't need to go down the micro$oft "we decide 
what you need" approach to our ports. The binary update question has been 
discussed at length in these forums. 

There is nothing to stop you from making a local ports tree to better suit 
your situation. But don't complain if you find conflicts with the port tools 
and/or ports. The ports that are considered universal are already included 
and maintained as part of the base system.

As was stated in earlier replies, you need the complete ports tree otherwise 
you are on your own.

As a port maintainer, it's quite enough work to keep things in sync with one 
ports tree without having to also worry about a second "convenience" tree 
that will only benefit a few users. The lack of willingness on your part to 
download the complete tree does not constitute a problem on our end.

Beech

>
> This new category would them be given priority in keeping
> their packages up to date. Could even take this idea one step
> further
> and say that only ports in this category will have packages
> built and keep up to date. All ports not in this special
> category will not have packages built at all. I think this
> would help the port group to better manager their people resources
> and serve the needs of the user community better.
>
> Another idea I would like to throw out to the list is how about
> requesting the ports group to add a function to packages so the
> installer of the package can select what version of the dependent
> components should be included in the install.
> Much like "make config" does in the ports system?
> The packages system already automatically launches the download
> of dependent packages so why not give the installer the option to
> select which version of the dependent to fetch.
> Like in php4/5 or mysql4/5 or apache 13/20. This way the package
> is more flexible and the port maintainer does not have to build
> a different version of the parent package for each version of
> the dependant which is available.
>
> The whole idea behind this post is to give the general users who
> reads this questions list an opportunity to brainstorm about ways to
> make the ports/package collection better and easier to use.
> This may help the ports group in understanding the needs and
> direction we the users would like to see the management of
> the collection to take.
> If we don't speak up they will just think things are ok as they are
> now.
> FreeBSD is a public project. The ports group are not the only
> users who can give input about the direction and policies
> concerning the future of the ports/package collection.
>
>
> All feedback welcome.
>
>
>
>
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to
> "[EMAIL PROTECTED]"

-- 

---------------------------------------------------------------------------------------
Beech Rintoul - Sys. Administrator - [EMAIL PROTECTED]
/"\   ASCII Ribbon Campaign  | Alaska Paradise
\ / - NO HTML/RTF in e-mail   | 201 East 9Th Avenue Ste.310
 X  - NO Word docs in e-mail | Anchorage, AK 99501
/ \  - Please visit Alaska Paradise - http://www.alaskaparadise.com
---------------------------------------------------------------------------------------











Attachment: pgpUCJLpO1omA.pgp
Description: PGP signature

Reply via email to