a proposal for the packaging system

[Munish Chopra]

On 2004-06-01 11:29 +0000, Eirik Nygaard wrote:
> Just so I want start another thread on this issue I'll reply to this one,
> I would just like to point out Simon 'corecode' Schubert's writeup about
> how the packaging system could look like. 
> 
> http://chlamydia.fs.ei.tum.de/~corecode/packaging.txt
> 

I read this when it first came up in Justin's log. While much of it
seems good (it'd be nice to have it categorized in some way, easier to
wrap your mind around it then :), there are two things that have struck
me since, and come up in discussion with people:

1. Rollback

   This isn't something to leave by the wayside. A lot of the admins
   I've spoken to are less than happy using ports for say, a critical
   Apache server. If they need to upgrade (security, etc.), and the new
   port is broken, they're toast. So they end up building everything
   from source without involving the ports system.
   I should note that there is a 'portdowngrade' app in FreeBSD ports
   now, which I haven't tried. Some sort of rollback mechanism should be
   part of the package system though. This is quite likely solvable in
   some fashion by having multiple versions of the same port installed
   (until you know the new one doesn't break some critical component of
   your infrastructure).

2. "A nice feature might be the availability of relative (binary)
   patchsets between certain versions (individually selected) to reduce
   consumed bandwidth and installation time. For binary patching systems
   see the bsdiff effort." [taken from Simon's text]

   I spoke to someone with significant experience in doing exactly that
   for a vendor, and was advised that while it may seem practical here
   and there, it's a road you really don't want to go down (for a
   ports-like system).

   Perhaps it is applicable for critical security patches or something
   in that manner, but for version upgrades it's a can of worms.

Anyway, it would be nice if the text could be organized into sections
like say "binary packages", "building from source", "build options",
etc. Just some way of giving structure to the document. That way, come
July (or whenever this discussion will start up again), we could pick up
each section, figure out the functionality that is deemed necessary, and
then work towards that. It's a simple approach, but surprisingly
effective in avoiding people talking past each other for days on end.

-- 
Munish Chopra