[gentoo-dev] Changelogs

[gentoo-dev] Changelogs

[Alec Warner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Recent discussion on this ML and on the portage-ml as well as
#gentoo-portage regarding pkg_warn() and the basic concept behind it.
We talked about adding new functionality, about adding a warning section
to the ebuild or to the metadata.  However.  all of these tend to have
problems.  The dev won't write the extra function, duplication of data
in pkg_{post/pre}inst, mangling of metadata.xml.

Portage current features the -l switch, to show changelogs.  It works
pretty well to show changes in packages prior to emerging.  For example,
emerge -uDpvl world -> shows what will emerge then shows the changelogs
for each package.  For a very large set of packages the output can be
overwhelming, however all the changelogs are provided and the user at
least has data to parse through.

The problem is that the ebuild is where all the action is, and the
changelogs lay empty.  Users cannot run most ebuild functions prior to
emerging packages ( usually pkg_postinst() for migrating instructions ),
thus any important messages that need to be seen that deal with the
package are only seen after it is installed.  This is bad because the
user is not warned ahead of time about any issues ( new library
installed, breaks new processes that link to it ).

Basically this is a suggestion for developers to put more information in
the changelog.  You are ( usually ) the maintainer, you know what the
program can do, what problems it can cause.  Putting this information in
pkg_postinst() is good, but putting it in the changelog is better.
Believe it or not; users actually read the changelog and hope at times
that it provides valuable information about the package and not "marked
stable on foo ( #41975 )".

Marking it stable on an arch and knowing that moving to stable has the
potential to break stable systems should be noted in the changelog, even
if there is just a pointer to a website, or to the ebuild itself to read
the pkg_postinst() and figure out wtf is going to happen.

*Marches toward better changelogs since most of the current logs are
rather skimpy on any details*

- -Ajec
warnera6@egr.msu.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQubrsWzglR5RwbyYAQI3dg/+KVFX4GctDzVjfhVDVDzGbx7q+T+0P+yf
AYOrsoWuFWcUh2/0FDV8z2aZ1P55M/SBWKgtFmkdMOGTUD34KGTZlyWMlcswxKfO
a3D43Dr1DQ6x66I2Gcf3VyHqpBgnPKgVhuNUiuFO8WD5N/W/sICLoTW415GEA7U7
jktDqrE+TDKBAdHvY2YaGD8iXZBX0zrS2v/1eeBLJ5/rSVVQfG9DICbMcRZ4lf5L
B6ktoarY5xjv6raE9wlZgrkjGpd7VoSn8yRnd10ekwftAlk1JKbAn8TIttWeMmYJ
9ZgLm/ZVjxAbzfoRhHjpw1nRb2q5oOeODfZQyOvlWFpZRhvMFySsDddfGsCbC2BS
Yf6pf8vKIMHRFLRSSupOl8agzHOm+CSGLHCpv+gs9sZ2eXzO2UjKqnN1VwoMO1sd
AJO/z28BvjqnBFU5WsTVmAxhuvziplrLTMfZP93k2VJ3zIni7NhKsLs4rJLnYbbP
xFg/Ji/YrZWwqXKFANYV2m/rw2HciKuFQzS2YmrZceAWjPz6s21m4yX6z+Hr1p+3
cu1TMIbZsg5ZA5V+nnmV1vfwW1fCLsyItOjYfv9IZi6JdupU22Lr3yR13wcUL6ZN
oFt3KmgLzZLjakXiIgICvKT9ZMKBMTkfkHh4qf6cxKmPHPan3Mi+5eBXmPWZ2oGQ
Q7gW3j/+Cps=
=Ymtl
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Changelogs

[Georgi Georgiev]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

maillog: 26/07/2005-22:05:49(-0400): Alec Warner types
> 
... skip some text that I mostly agree with...
> 

I mentioned this before, but it would be nice to somehow mark important
messages in the changelog. Prefix them with something, say "WARNING
around there", anything, as long as it is agreed upon and everybody uses
it. Changelogs are huge and even if portage is not made to show only the
relevant *important* information, it would be nice to have an easy way
to see it by grepping the output of emerge -l.

-- 
()   Georgi Georgiev   () You will receive a legacy which will place   ()
()    chutz@gg3.net    () you above want.                              ()
()  +81(90)2877-8845   ()                                              ()

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Changelogs

[Duncan]

Georgi Georgiev posted <20050727022212.GB10581@lion.gg3.net>, excerpted
below,  on Wed, 27 Jul 2005 11:22:12 +0900:

> maillog: 26/07/2005-22:05:49(-0400): Alec Warner types
>> 
> ... skip some text that I mostly agree with...
>> 
>> 
> I mentioned this before, but it would be nice to somehow mark important
> messages in the changelog. Prefix them with something, say "WARNING around
> there", anything, as long as it is agreed upon and everybody uses it.
> Changelogs are huge and even if portage is not made to show only the
> relevant *important* information, it would be nice to have an easy way to
> see it by grepping the output of emerge -l.

Note that most of the previously mentioned "stable on foo, bug #000000"
entries relate to one of two things.  (1) A security bugfix (the majority
of the cases). (2) A specific request to stabilize the package, either
from the package maintainer to the archs (so the maintainer can remove old
versions without removing the latest stable for arch foo), or from users
reporting stability of a ~ package and no bugs for 30 days, thus
requesting a nudge to stable.

Thus, it's generally safe (from my experience) to skip-over further
investigation of these entries.  On critical packages, however, I'll look
into all the "fix for #000000" type entries.

Generally, however, the biggest compatibility issues will be on "version
bump" type entries.  It's important to realize, however, just what the
Gentoo changelogs (as opposed to the upstream changelogs) document --
Gentoo, that is, primarily ebuild, changes.  A version bump is often a
trivial change in terms of the ebuild and where Gentoo is concerned, even
where it's a HUGE change in terms of configuration and upstream. 
Therefore, the Gentoo changelog contains the information it should, simply
noting the version bump.  If the package is critical and you are on a
mission critical machine that you can't afford to have down for a few
hours while you straighten things out, every time you see a "version bump"
Gentoo changelog entry, it's a flag meaning "go and checkout the upstream
changelog, if you care about the smooth operation of your machine!"

Now, granted, if the Gentoo devs know about a particular config change
that could mess things up, putting that in the Gentoo changelog can be a
good thing, and actually, it seems to me that Gentoo devs ARE fairly good
about this.  Where they know there will be issues, they document them both
in the changelog, and for big ones, often by creating upgrade guides and
the like, and by posting notices on the Gentoo front page and in GWN. 
However, that in no way means they /have/ to do such things.  A
responsible sysadmin (which hopefully means every Gentoo user doing
upgrades, they being the sysadmins on their systems) WILL checkout version
bump info, if it's a mission critical application on a mission critical
machine.

Note that I don't always do so here, but that's because computing is a
hobby for me, not a job, I'm running ~arch and occasionally unmasking
stuff that's hard masked for testing, so I too can test it, and I
expect not entirely smooth upgrades from time to time.  I do basic due
diligence checking changelogs and keeping up with the general state of
things on packages I consider critical, but don't worry too much about
individual upgrades causing issues, since it's not a problem for me to
reboot, if necessary to a rescue partition, and/or spend an hour or two
fixing things, should they break.

There are, however, two issues with changelogs that DO frustrate me.

1) I like to know exactly what's behind any of those [ UD] things that
come up occasionally, the "forced" downgrades.  emerge -pl doesn't work
for those, and I wish it did.  I have to manually view the changelog,
typing in the specific path to it in the portage tree in ordered to do so,
to see what's up in these types of cases.  It'd be very nice to have
portage's changelog viewing functionality take negative ranges as well,
since that's effectively what's happening here.  This issue has of course
been raised before and the feature may get into a future version of
portage, but it may be awhile.

2) I get frustrated with the changelog for portage itself.  Again, keeping
in mind the purpose of the portage tree changelogs, to document ebuild
changes, not upstream code changes, not having a working portage tree
changelog for portage itself does make some sense, given the fact that
it's a Gentoo project and thus that we ARE the upstream.  However, the
fact remains, there exists no easy way to access perhaps VERY vital
change documentation, without first merging the upgrade to get the
changelog in /usr/share/doc/portage-xxxx/.  Yes, one can use -p, see
portage is on the list, do a fetch, then manually extract the changelog
and see what's up, or one can visit the website and check it out there,
but for such a critical part of a Gentoo machine's infrastructure, one
would certainly wish for something a bit easier than either of these. 
baselayout and udev, among other Gentoo or semi-Gentoo developed packages,
manage decent in-tree logs, why can't portage do so as well?

Maybe what's needed to address #2 is simply to include a separate portage
changelog file, somewhere within the tree, possibly as its own package, or
in the profiles root dir, along with the global package.mask, and use.desc
and use.local.desc files.  Portage could then add an "emerge portinfo"
function, similar to "emerge info", that would spit out the "upstream"
changelog between what's currently installed, and any new version.

Expanding on the idea a bit further, what about creating a generic "emerge
changelog" function, that fetches the tarball if necessary, then extracts
only the changelog, and opens it for viewing (presumably using the $PAGER
environmental variable to determine what to display it with)?  Naturally,
given Gentoo can't control the upstream changelog format, enforcing
parseability rules as it does for its own, the entire changelog would of
necessity be displayed, leaving the user to figure out the relevant
cutoffs instead of doing it automatically as emerge -pl does with the
portage tree changelogs, but it'd still be a rather easier way to view
upstream changelogs before installation (or for that matter, after) than
we have now.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Changelogs

[Michael Cummings]

On Tue, 26 Jul 2005 21:16:53 -0700
Duncan <1i5t5.duncan@cox.net> wrote:
> 
> Maybe what's needed to address #2 is simply to include a separate
> portage changelog file, somewhere within the tree, possibly as its own
> package, or in the profiles root dir, along with the global
> package.mask, and use.desc and use.local.desc files.  Portage could
> then add an "emerge portinfo" function, similar to "emerge info", that
> would spit out the "upstream" changelog between what's currently
> installed, and any new version.

or just a dodoc ChangeLog and have it tossed in the same share dir we
toss upstream docs/changelogs/readmes

/me is not weighing in with an opinion on this, mind you, just saying
there might be an even simpler way to include that info
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Changelogs

[Simon Stelling]

Hi,

Duncan wrote:
> and see what's up, or one can visit the website and check it out there,
> but for such a critical part of a Gentoo machine's infrastructure, one
> would certainly wish for something a bit easier than either of these. 

Erm, is that a joke? You want an easier way than browsing to a web page
and read? Why should portage go different ways than every other software
project?

> Expanding on the idea a bit further, what about creating a generic "emerge
> changelog" function, that fetches the tarball if necessary, then extracts
> only the changelog, and opens it for viewing (presumably using the $PAGER
> environmental variable to determine what to display it with)?  Naturally,
> given Gentoo can't control the upstream changelog format, enforcing
> parseability rules as it does for its own, the entire changelog would of
> necessity be displayed, leaving the user to figure out the relevant
> cutoffs instead of doing it automatically as emerge -pl does with the
> portage tree changelogs, but it'd still be a rather easier way to view
> upstream changelogs before installation (or for that matter, after) than
> we have now.

Portage is a package manager. package managers have to manage package
versions and their dependencies. They do NOT have to be fancy changelog
readers. As you already stated, it's not the developers responsibility
to get you upgrade information. While I can see a great benefit in
putting important information into the changelog, I really can't see why
portage should provide functions to read a changelog, when nearly all
packages provide the same information on their homepages. Additionally,
if you really have to read the changelog before emerging the new
version, the information is really important, and I'm sure it will show
up in portage's changelog.

Please don't make portage a news reader.

Regards,

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Changelogs

[Michael Cummings]

On Wed, 27 Jul 2005 14:13:12 +0200
Simon Stelling <blubb@gentoo.org> wrote:
> 
> Please don't make portage a news reader.

Compelling - I tend to agree. It'd be nice if some python-wise
individual(group) wrote a tool that could interact with the portage api
enough to get the update list to see what would be updated, then parse
the changelogs - separate from portage, but interacting just enough to
know what's on the list for upgrades/downgrades/reinstalls. Of course,
this still wouldn't account for the massive developer tax effort for
rewriting changelogs to adapt to the tool - or remembering to write
changelogs with new markers.

ick. nice ideas, but tough to enact i think.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Changelogs

[Alin Nastac]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

Michael Cummings wrote:

>On Wed, 27 Jul 2005 14:13:12 +0200
>Simon Stelling <blubb@gentoo.org> wrote:
>  
>
>>Please don't make portage a news reader.
>>    
>>
>
>Compelling - I tend to agree. It'd be nice if some python-wise
>individual(group) wrote a tool that could interact with the portage api
>enough to get the update list to see what would be updated, then parse
>the changelogs - separate from portage, but interacting just enough to
>know what's on the list for upgrades/downgrades/reinstalls. Of course,
>this still wouldn't account for the massive developer tax effort for
>rewriting changelogs to adapt to the tool - or remembering to write
>changelogs with new markers.
>
>  
>
Changelogs are beggining to be too large already.
sooner or later, portage team will move 'em somewhere outside the
portage tree.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [gentoo-dev] Re: Changelogs

[Alec Joseph Warner]

Simon Stelling wrote:
> Hi,
> 
> Duncan wrote:
> 
>>and see what's up, or one can visit the website and check it out there,
>>but for such a critical part of a Gentoo machine's infrastructure, one
>>would certainly wish for something a bit easier than either of these. 
> 
> 
> Erm, is that a joke? You want an easier way than browsing to a web page
> and read? Why should portage go different ways than every other software
> project?
> 
> 
>>Expanding on the idea a bit further, what about creating a generic "emerge
>>changelog" function, that fetches the tarball if necessary, then extracts
>>only the changelog, and opens it for viewing (presumably using the $PAGER
>>environmental variable to determine what to display it with)?  Naturally,
>>given Gentoo can't control the upstream changelog format, enforcing
>>parseability rules as it does for its own, the entire changelog would of
>>necessity be displayed, leaving the user to figure out the relevant
>>cutoffs instead of doing it automatically as emerge -pl does with the
>>portage tree changelogs, but it'd still be a rather easier way to view
>>upstream changelogs before installation (or for that matter, after) than
>>we have now.
> 
> 
> Portage is a package manager. package managers have to manage package
> versions and their dependencies. They do NOT have to be fancy changelog
> readers. As you already stated, it's not the developers responsibility
> to get you upgrade information. While I can see a great benefit in
> putting important information into the changelog, I really can't see why
> portage should provide functions to read a changelog, when nearly all
> packages provide the same information on their homepages. 
  Because the functionality already exists and is in stable portage? 
Because some developers maintain system critical packages that can cause 
large amounts of breakage and get complaints from users when things 
break?  Gentoo is a distribution and there is some responsibility to 
provide users upgrade paths when packages switch versions.  Gentoo isn't 
just portage, IMHO.

Additionally,
> if you really have to read the changelog before emerging the new
> version, the information is really important, and I'm sure it will show
> up in portage's changelog.
> 
> Please don't make portage a news reader.
> 
> Regards,
> 
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Changelogs

[Simon Stelling]

Alec Joseph Warner wrote:
>> to get you upgrade information. While I can see a great benefit in
>> putting important information into the changelog, I really can't see why
>> portage should provide functions to read a changelog, when nearly all
>> packages provide the same information on their homepages. 
> 
>  Because the functionality already exists and is in stable portage?
> Because some developers maintain system critical packages that can cause
> large amounts of breakage and get complaints from users when things
> break?  Gentoo is a distribution and there is some responsibility to
> provide users upgrade paths when packages switch versions.  Gentoo isn't
> just portage, IMHO.

Note, we're talking about upstream's changelog, not portage's one. There
is no feature to read upstream's changelog through portage *before*
merging it. I agree that Gentoo is more than Portage, and it
definitively should provide upgrade paths where necessary, but not by
implementing such a feature. It's far easier to stick a note into the
Changelog/post_pkg() saying "There were major changes in this release,
please carefully read the changelog at http://www.upstream.org/."

Regards,

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Changelogs

[Alec Joseph Warner]

Simon Stelling wrote:
> Alec Joseph Warner wrote:
> 
>>>to get you upgrade information. While I can see a great benefit in
>>>putting important information into the changelog, I really can't see why
>>>portage should provide functions to read a changelog, when nearly all
>>>packages provide the same information on their homepages. 
>>
>> Because the functionality already exists and is in stable portage?
>>Because some developers maintain system critical packages that can cause
>>large amounts of breakage and get complaints from users when things
>>break?  Gentoo is a distribution and there is some responsibility to
>>provide users upgrade paths when packages switch versions.  Gentoo isn't
>>just portage, IMHO.
> 
> 
> Note, we're talking about upstream's changelog, not portage's one. There
> is no feature to read upstream's changelog through portage *before*
> merging it. I agree that Gentoo is more than Portage, and it
> definitively should provide upgrade paths where necessary, but not by
> implementing such a feature. It's far easier to stick a note into the
> Changelog/post_pkg() saying "There were major changes in this release,
> please carefully read the changelog at http://www.upstream.org/."
> 
A.  In some instances, those notes never show up in the changelog
B.  pkg_postinst() doesn't cut it, because the damage is already done in 
that phase.

I would be very supportive of A.  Just a note in the gentoo changelog 
saying Warning: this upgrade could cause problems, see the project 
homepage for details.

Right now it is not always possible to destinguish between a safe 
upgrade and one that the developers know is dangerous.  I am simply 
advocating a standard string in the changelog ( so that it's grep-able ) 
warning the user about potential problems.  No long speeches in the 
changelog about it.

> Regards,
> 
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Changelogs

[Georgi Georgiev]

maillog: 27/07/2005-10:00:52(-0400): Alec Joseph Warner types
> I would be very supportive of A.  Just a note in the gentoo changelog 
> saying Warning: this upgrade could cause problems, see the project 
> homepage for details.

+1 here

-- 
/    Georgi Georgiev   /  "...[Linux's] capacity to talk via any       /
\     chutz@gg3.net    \  medium except smoke signals." (By Dr. Greg   \
/   +81(90)2877-8845   /  Wettstein, Roger Maris Cancer Center)        /
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Changelogs

[Jason Stubbs]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

On Wednesday 27 July 2005 22:19, Alec Joseph Warner wrote:
> Gentoo is a distribution and there is some responsibility to provide users
> upgrade paths when packages switch versions.  Gentoo isn't just portage,
> IMHO. 

Perhaps the first thing you've ever said that I've agreed with right off
the bat. ;)

The average system would probably have about five new updatable packages
every single day. Shouldn't users expect that upgrading them is not going to
break things? Isn't that the whole point of ~arch? Excluding the cases where
breakage is due to not updating config files, any breakage that may happen
from upgrading that can't be dealt with within the limits of an ebuild really
must be disseminated(sp?) to the users.

--
Jason Stubbs

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Changelogs

[Jason Stubbs]

[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]

On Wednesday 27 July 2005 11:05, Alec Warner wrote:
> 
> Recent discussion on this ML and on the portage-ml as well as
> #gentoo-portage regarding pkg_warn() and the basic concept behind it.
> We talked about adding new functionality, about adding a warning section
> to the ebuild or to the metadata.  However.  all of these tend to have
> problems.  The dev won't write the extra function, duplication of data
> in pkg_{post/pre}inst, mangling of metadata.xml.

Quicker closer than me! ;)

> Portage current features the -l switch, to show changelogs.  It works
> pretty well to show changes in packages prior to emerging.  For example,
> emerge -uDpvl world -> shows what will emerge then shows the changelogs
> for each package.  For a very large set of packages the output can be
> overwhelming, however all the changelogs are provided and the user at
> least has data to parse through.

"The dev won't write the extra function"
Same problem, no?

Not sure what you meant by "duplication of data" or "mangling of metadata.xml"
but I still don't see why pkg_warn() can't work. Those that are writing stuff
in pkg_postinst() presently can use pkg_warn() and feel warm and fuzzy knowing
that more people are making use of the information. Those that don't make use
of it? No different to not making use of pkg_postinst().

If you could explain what you meant by the other two listed issues?

-- 
Jason Stubbs

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Changelogs

[Alec Warner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jason Stubbs wrote:
> On Wednesday 27 July 2005 11:05, Alec Warner wrote:
> 
>>Recent discussion on this ML and on the portage-ml as well as
>>#gentoo-portage regarding pkg_warn() and the basic concept behind it.
>>We talked about adding new functionality, about adding a warning section
>>to the ebuild or to the metadata.  However.  all of these tend to have
>>problems.  The dev won't write the extra function, duplication of data
>>in pkg_{post/pre}inst, mangling of metadata.xml.
> 
> 
> Quicker closer than me! ;)
> 
> 
>>Portage current features the -l switch, to show changelogs.  It works
>>pretty well to show changes in packages prior to emerging.  For example,
>>emerge -uDpvl world -> shows what will emerge then shows the changelogs
>>for each package.  For a very large set of packages the output can be
>>overwhelming, however all the changelogs are provided and the user at
>>least has data to parse through.
> 
> 
> "The dev won't write the extra function"
> Same problem, no?
> 
> Not sure what you meant by "duplication of data" or "mangling of metadata.xml"
> but I still don't see why pkg_warn() can't work. Those that are writing stuff
> in pkg_postinst() presently can use pkg_warn() and feel warm and fuzzy knowing
> that more people are making use of the information. Those that don't make use
> of it? No different to not making use of pkg_postinst().
> 
> If you could explain what you meant by the other two listed issues?
> 

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?

In the latter case all that is really needed is some sort of switch (
NOT a use flag ) that says this package causes problems, look at
UPSTREAMS webpage for migration information.  I am not particularly in
favor of that, but it's simple for a developer to do, and it's simple
for me to check out a potential 4 or 5 packages in a given upgrade to
figure out what I have to do.

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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQuggmWzglR5RwbyYAQIOPhAAj9ugQNjuz8Ij218QEO3Tp2EY1kN/D0rL
C7Fqj8RX5yn1QL+R+TR9m1e+pkmigfFIWnmMxwzrUsYupd7I9hXgGiHaVD9L6//A
wIdqBBrxZ4JXp4S3nzrWWKtPOx3Cgdf++cYOPwDnOME7XOV5qYj0v+iLeKx89xGN
QUkRQNlK8/mBLabgOSmzffOQbQvq6qr02DNdXYFgb4JZg3MaJ+KtAZnDseutzzc4
DYrhpz82gXdRdYPwHthdcSqcFWhh9I+3hp4f+piFBl8L+5wKIch3fUjQn3wDDhDr
EVGh4mvrCAUlnI/I00YK/kcxkIdf3132gz7hKlUVHNlbf8ClvnwEM9aUzeOZTgWw
YGfyCjdcuFxX5t3VeDJgbe/YdXzAmhRDZfSVu+uw+rPPuyFHLttbA65bSn1RvaLd
bn5VXGGeP71QnhtNX2HKRhsLIiwtIcePt4vTRiuRjKWrZ7tR7jVDQ+CtzCNpj1y0
9PlHBDs3uyuBwp/xbtYqB/YMLnC3CRVMHMF93jiD4NQzZXRCIcn2LzxUkBa6KGh/
t4NIFCkfiJtK0enGe/nZOy1rh9cza9tFBi4UbxXDmfR+8mX8wHyl52LBUnltAjC8
D07xUZVUESW5qnP+QTSwLosOs9b6u4GhvcehnQCSUVXWeZFhkVfn/Kfk/1C7ArTQ
TrU1YwNLVco=
=nf8R
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Changelogs

[Jason Stubbs]

[-- Attachment #1: Type: text/plain, Size: 2062 bytes --]

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 #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Changelogs

[Maurice van der Pot]

[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]

On Tue, Jul 26, 2005 at 10:05:49PM -0400, Alec Warner wrote:
> Recent discussion on this ML and on the portage-ml as well as
> #gentoo-portage regarding pkg_warn() and the basic concept behind it.
> We talked about adding new functionality, about adding a warning section
> to the ebuild or to the metadata.  However.  all of these tend to have
> problems.  

> The dev won't write the extra function, 
In your proposal this would be "the dev won't write the extra changelog
content" and ...

> duplication of data in pkg_{post/pre}inst, 
... "duplication of data in Changelog/pkg_post".


> mangling of metadata.xml.
I don't know what this means, but I don't think pkg_warn has this
problem.

So I don't see any advantage of putting it in the changelog. I actually
like the pkg_warn idea much better. 

So tell me again, what does your proposal solve of the problems you see
with pkg_warn?

Regards,
Maurice.

-- 
Maurice van der Pot

Gentoo Linux Developer   griffon26@gentoo.org     http://www.gentoo.org
Creator of BiteMe!       griffon26@kfk4ever.com   http://www.kfk4ever.com


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Changelogs

[Alec Joseph Warner]

Maurice van der Pot wrote:
> On Tue, Jul 26, 2005 at 10:05:49PM -0400, Alec Warner wrote:
> 
>>Recent discussion on this ML and on the portage-ml as well as
>>#gentoo-portage regarding pkg_warn() and the basic concept behind it.
>>We talked about adding new functionality, about adding a warning section
>>to the ebuild or to the metadata.  However.  all of these tend to have
>>problems.  
> 
> 
>>The dev won't write the extra function, 
> 
> In your proposal this would be "the dev won't write the extra changelog
> content" and ...
> 
> 
>>duplication of data in pkg_{post/pre}inst, 
> 
> ... "duplication of data in Changelog/pkg_post".
> 
> 
> 
>>mangling of metadata.xml.
> 
> I don't know what this means, but I don't think pkg_warn has this
> problem.
> 
> So I don't see any advantage of putting it in the changelog. I actually
> like the pkg_warn idea much better. 
> 
> So tell me again, what does your proposal solve of the problems you see
> with pkg_warn?
  -l support for reading changelogs is already in portage, pkg_warn 
support would only be in CVS which won't be out for a long time(*), and 
pkg_warn() doesn't fit in with the rest of the ebuild functions.  This 
solution is done now, in the changelog, to be viewed by users.  Metadata 
ideas were not liked because metadata is not versioned and the parsing 
would not be easy.

* Long time being whenever, not starting a flamewar about it.

> Regards,
> Maurice.
> 
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Changelogs

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alec Joseph Warner wrote:
| solution is done now, in the changelog, to be viewed by users.  Metadata
| ideas were not liked because metadata is not versioned and the parsing
| would not be easy.

The metadata dtd explicitly supports versioning. It looks like it even
supports full changelog functionality.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC59KDXVaO67S1rtsRAsooAJ9dUqpTDUX/p/E6vm8wNzYBhwhLpwCgtGaW
7lwLAwI84ydE4YZK4aHEYjw=
=gQz1
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list