On Thursday 28 July 2005 09:02, Alec Warner wrote:
> In hindsight, arguing over almost two different things.  We both agree
> that upgrade paths for changes that break the system are good, and that
> information regarding the upgrade path *SHOULD* be provided in some
> manner.  Some developers think that providing detailed instructions in
> pkg_postinst() is good, others will direct you to a website ( usually
> UPSTREAM's webpage ) which has the instructions; it saves them time.
> Which is correct, or are both?

Both are correct. Some developers are willing to put the effort into getting
upgrade info immediately before the user and some are happy with the user
putting 50% of the effort. Either is fine, but you're also missing major
changes that happen in ebuilds themselves.

The real point, though, is that there should be a consistent way for this
information to be delivered to users. Whether is be via ChangeLog,
metadata.xml or pkg_warn(), the requirement is that developers are able
to provide as little or much information as they want in such a way that
users get easy access to it.

> In the former case where more specific information is provided to the
> user by portage you generally want a more complex system.  You want the
> 
> "<warn from="2.6.4:2[baduse]" to="2.7[-baduse]">You enabled baduse?
> Removing it will rm -rf /!</warn>" syntax ( from our conversation last
> night ) which is decidedly more complex to write and more complex to parse,
> 
> Don't get me wrong, I like it, but I doubt it will get used by enough
> people to be useful.

I never said I wanted that. I just used it to illustrate how it could be
easily handled in metadata.xml rather than pkg_warn() if necessary. Nor
is it complex to write or parse. My heart is not set on the above in any way
whatsoever, though.

I think you might be jumping to a solution without fully considering the
problem. On the whole, this is a relatively small problem anyway, so
an immediate solution is not really necessary.

-- 
Jason Stubbs

Attachment: pgpX0phbfhYO9.pgp
Description: PGP signature

Reply via email to