Re: Ideas and questions on pkgsrc

[Aggelos Economopoulos <aoiko@xxxxxxxxxxxxxx>]

Justin C. Sherrill wrote:
> So, after seeing that PostgresQL is moving services from FreeBSD to Debian
> because of ease of packaging, and seeing Ivan Voras's idea for a "stable"
> branch of ports similar to the quarterly pkgsrc releases, I've been
> thinking about the pkgsrc service.
> 
> (Here's the links for the aforementioned items:)
> 
> http://blog.hagander.net/archives/167-PostgreSQL-infrastructure-updates.html
> 
> http://ivoras.sharanet.org/blog/tree/2010-04-11.of-ports-and-men.html
> 
> Here's my thoughts.  Platform viability is being determined mostly by how
> well it handles the software installation and availability.  Ports has
> historically been a big reason for FreeBSD, and I'd argue that the best
> thing in Debian/Ubuntu is apt-get.  PC-BSD has rolled their own packaging
> method for similar reasons.  So, it stands to reason that the easier it is
> to use pkgsrc on DragonFly, the better off DragonFly will be.  I've seen a
> number of new people come into #dragonflybsd on EFNet recently asking
> questions about their first install, and one of the first answers is
> usually "pkg_radd".  I love that we have such an easy tool for quick
> installs.
> 
> I and probably a good chunk of the people reading this are now used to
> pkgsrc and DragonFly and can deal with various issues, but I worry that
> being used to it makes it harder for us to see/fix these problems.  I'm
> looking for some ideas or suggestions on what we could do.

Well, I for one can't get used to some of the pkgsrc issues (see below).

> I've been thinking -
> 
>  - A first-time guide on the website and maybe the LiveDVD desktop that
> talks about common packages to install via pkg_radd so people don't have
> to guess names.

Directing them towards pkg_search should help, no?

>  - Are there other contrib/ items we can move to pkgsrc?

Aside from cvs, I don't see any obvious candidates. We need a lot of
stuff for our build, other stuff carries local patches that are hard to
get upstream, other stuff (nvi, less, file) is very useful to have and
are not really a burden.

We should eventually move sendmail out of base (setting up dma by
default), but I'm not sure how easy that is and what's the sendmail
status in pkgsrc.

>  - Would it be useful to see all the bulk build reports from
> i386/x86_64/2.6/2.7 that I build?

It might, so sure.

>  - Would it be worth having a separate mailing list for those reports? 
> They can be pretty frequent - several per day.

Dunno.

>  - Should we explore putting more onto the LiveDVD?

Maybe. What would be the use case scenario?

My by far most important gripe w/ pkgsrc is the inability to do mass
upgrades from binary packages in a straightforward manner. Not even sure
if it's anything the pkgsrc developers are concerned with.

> Things I could use help with:
>  - The crontab output from the bulk builds will list the new packages from
> each build.  It's rsync output, so anything with a -> : "net/foo-1.2 ->
> net/foo-1.2".  If someone can come up with a script that parses out those
> lines from emails and can create an email or webpage showing what's
> updated for which arch, that would really help people.

What would you want that for? To the admin, having a way to ask "For
which of my installed packages are there newer versions that I can
upgrade too" sounds more useful.

>  - General ideas about the bulk builds and binary installs; I've been
> staring at it so long I can't see the forest because there's all these
> trees in the way.

Like I have asked in the past, NOT having incomplete (while packages are
uploading) package sets be visible would be very useful. At the very
least we should have a way to detect that case manually.

I don't think we can solve all the problems on our own. I bet NetBSD
people are coming up against some of them too. Anybody know what their
policies are and what, if anything, is coming down the pipeline as a
solution?

Aggelos