Re: [gentoo-dev] Changelogs
-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
"You enabled baduse?
Removing it will rm -rf /!" 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
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
pgpeZuTWTQpaq.pgp
Description: PGP signature
Re: [gentoo-dev] Changelogs
-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
Re: [gentoo-dev] Changelogs
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
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 [EMAIL PROTECTED] http://www.gentoo.org
Creator of BiteMe! [EMAIL PROTECTED] http://www.kfk4ever.com
pgpt0L7dVImnB.pgp
Description: PGP signature
Re: [gentoo-dev] app-text/pstotext in danger of becoming security masked
On Wed, 2005-07-27 at 11:23 +0200, Stefan Cornelius wrote: > app-text/pstotext has a serious remote vulnerability that allows to > execute arbitrary commands on a vulnerable system. It appears to be > unmaintained at the moment. > > If anyone out there is able to take this on and patch it (honestly, > patch is small), that would be much appreciated, the bug number is > 100245. Otherwise, it's our intent to security mask the package in the > next 24 hours. fixed > > Thanks in advance, > Stefan -- Ned Ludd <[EMAIL PROTECTED]> -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Changelogs
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 / \ [EMAIL PROTECTED]\ 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
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 pgpwrLcUEoacF.pgp Description: PGP signature
Re: [gentoo-dev] Re: Changelogs
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
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 [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: upgrade's and rc-scripts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian D. Harring wrote: > Vapier had suggested yanking (on unmerge, not replacement) any > config_protected file that has the same md5/mtime as what it was > originally merged with. As and end-user, that would be mana from heaven. :) Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC54/V2QTTR4CNEQARAlm5AJ0b9i6pwfN62FLn/rHNvrkCXDN8VACgnghT s3MyShSLliagonr06yE2M2Q= =QSzI -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Changelogs
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
Michael Cummings wrote: >On Wed, 27 Jul 2005 14:13:12 +0200 >Simon Stelling <[EMAIL PROTECTED]> 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. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Changelogs
On Wed, 27 Jul 2005 14:13:12 +0200 Simon Stelling <[EMAIL PROTECTED]> 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
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 [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Changelogs
On Tue, 26 Jul 2005 21:16:53 -0700 Duncan <[EMAIL PROTECTED]> 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
[gentoo-dev] app-text/pstotext in danger of becoming security masked
app-text/pstotext has a serious remote vulnerability that allows to execute arbitrary commands on a vulnerable system. It appears to be unmaintained at the moment. If anyone out there is able to take this on and patch it (honestly, patch is small), that would be much appreciated, the bug number is 100245. Otherwise, it's our intent to security mask the package in the next 24 hours. Thanks in advance, Stefan -- gentoo-dev@gentoo.org mailing list
