Re: Lenny upgrade-advisor
Hi! Am 7.9.2008 schrieb "Franklin PIAT" <[EMAIL PROTECTED]>: >I've worked on an upgrade advisor tool for Lenny. The idea is to do some >sanity check to then warn the users of potential problems (and also >advertise some best practices). The example below should be quite >explicit. Wonderfull idea! Are you "synchronizing" with the release notes? Meaning, that you things you test, are documented there and vice versa? Best regards, Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: user-visible list of divergences from upstream
On Tue Sep 09 08:34, Reinhard Tartler wrote: > BTH, I think the maintainer's time is way better spend with > documententing their patches properly. > I concur. patch-tracking.debian.net is the way forward. Integrating it with as many other services as possible is, of course, always good Matt -- Matthew Johnson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: user-visible list of divergences from upstream
On Tue, Sep 09, 2008 at 08:29:00AM +0100, Matthew Johnson wrote: > I concur. patch-tracking.debian.net is the way forward. Integrating it > with as many other services as possible is, of course, always good See #497410 and #498313. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ I'm still an SGML person,this newfangled /\ All one has to do is hit the XML stuff is so ... simplistic -- Manoj \/ right keys at the right time signature.asc Description: Digital signature
ITP: libclass-std-utils-perl -- This module provides three utility subroutines
Package: wnpp Severity: wishlist Owner: Xavier Oswald <[EMAIL PROTECTED]> * Package name: libclass-std-utils-perl Version : 0.0.3 Upstream Author : Damian Conway <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/Class-Std-Utils/ * License : GPL Programming Lang: Perl Description : Utility subroutines for building "inside-out" objects This module provides three utility subroutines that simplify the creation of "inside-out" classes. See Chapters 15 and 16 of "Perl Best Practices" (O'Reilly, 2005) for details. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) -- ,''`. Xavier Oswald <[EMAIL PROTECTED]> : :' : GNU/LINUX Debian Maintainer `. `' GnuPG Key ID 0x88BBB51E `-938D D715 6915 8860 9679 4A0C A430 C6AA 88BB B51E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: user-visible list of divergences from upstream
Ben Finney wrote: > "Eugene V. Lyubimkin" <[EMAIL PROTECTED]> writes: > >> Many of Debian packages have a patches that fixes some important >> bugs which have not accepted by upstream for some reasons, some of >> them also contains improvements, Debian-specific or not. > […] > >> But how can users know about this changes in Debian packages? > > By the existing README.Debian and NEWS.Debian conventions (for > persistent and version-sensitive changes, respectively). > Have non-Debian users access to this files? Have Debian users access to these files when packages are not installed on system? And when changes are not persistent (for example, important backported fix for stable release)? -- Eugene V. Lyubimkin aka JackYF signature.asc Description: OpenPGP digital signature
Re: Proposal: user-visible list of divergences from upstream
Reinhard Tartler wrote: > "Eugene V. Lyubimkin" <[EMAIL PROTECTED]> writes: > >> I failed to fetch a human-readable patch info for psi in testing from >> patch-tracking.debian.net, for example. > > Okay, take another example then: > http://patch-tracking.debian.net/package/ffmpeg-debian Well, how can users go this site? Is it described in debian policy, devreference, some user docs? >> Also, it would be better to combine several patch into one >> user-visible change in some cases, some patches may not be not >> "listed" at all; typos' fixes in documentation are good, but not too >> serious changes to end users, for example. > > I think it is rather hard to draw a line here, because it very much > depends on the POV of the user. End-users are likely not interested in > the source of a program, they want to use it. (Prospective) Maintainers > and upstreams of the package are interested in seeing all patches > anyways. What kind of users would be interested only in "end-user > visible" changes and is it worth the efford of the maintainer to decide > on this? (suppose) I'm a system administrator. I have received new production mail server. My only choice is a stable well-maintained distribution. Last release for RedHat contains exim 1.5.19, and Debian version is 1.5.18. I know about recently found security bug in 1.5.18. What distribution I will choose without official acknowledge that Debian's source for 1.5.18 already have a backported fix for bug? Well, for security bugs Debian have DSAs. But for other non-security fixes and improvements came to stable release? Many users don't except at all that Debian patches upstream when needed. -- Eugene V. Lyubimkin aka JackYF signature.asc Description: OpenPGP digital signature
Re: Proposal: user-visible list of divergences from upstream
On Tue, 2008-09-09 at 14:33 +0300, Eugene V. Lyubimkin wrote: > Reinhard Tartler wrote: > > "Eugene V. Lyubimkin" <[EMAIL PROTECTED]> writes: > > > >> I failed to fetch a human-readable patch info for psi in testing from > >> patch-tracking.debian.net, for example. > > > > Okay, take another example then: > > http://patch-tracking.debian.net/package/ffmpeg-debian > Well, how can users go this site? Is it described in debian policy, > devreference, some user docs? It could be linked from the PTS maybe - i.e. package specific - and then mentioned in the Debian Developer Reference or linked from http://www.uk.debian.org/devel/ under Miscellaneous. In most cases, upstream teams should be able to get the majority of the data needed from the PTS using http://packages.qa.debian.org/$package and then the BTS. > (suppose) I'm a system administrator. I have received new production > mail server. My only choice is a stable well-maintained distribution. > Last release for RedHat contains exim 1.5.19, and Debian version is > 1.5.18. I know about recently found security bug in 1.5.18. What > distribution I will choose without official acknowledge that Debian's > source for 1.5.18 already have a backported fix for bug? > Well, for security bugs Debian have DSAs. But for other non-security > fixes and improvements came to stable release? BTS and online changelogs linked from the PTS ? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Proposal: user-visible list of divergences from upstream
Neil Williams wrote: > On Tue, 2008-09-09 at 14:33 +0300, Eugene V. Lyubimkin wrote: >> Reinhard Tartler wrote: [snip] >>> http://patch-tracking.debian.net/package/ffmpeg-debian >> Well, how can users go this site? Is it described in debian policy, >> devreference, some user docs? > > It could be linked from the PTS maybe - i.e. package specific - and then > mentioned in the Debian Developer Reference or linked from > http://www.uk.debian.org/devel/ under Miscellaneous. In most cases, > upstream teams should be able to get the majority of the data needed > from the PTS using http://packages.qa.debian.org/$package and then the > BTS. Yes, this would be good anyway. >> (suppose) I'm a system administrator. I have received new production >> mail server. My only choice is a stable well-maintained distribution. >> Last release for RedHat contains exim 1.5.19, and Debian version is >> 1.5.18. I know about recently found security bug in 1.5.18. What >> distribution I will choose without official acknowledge that Debian's >> source for 1.5.18 already have a backported fix for bug? > >> Well, for security bugs Debian have DSAs. But for other non-security >> fixes and improvements came to stable release? > > BTS and online changelogs linked from the PTS ? For upstream, for Debian people - enough. My proposal is to make user-oriented list. Long changelog entries with some inner packaging info and other stuff and viewing dozen of patches (even with good comments) imho, is not what user have to do to answer on the simple questions "Have Debian version of package foo, version x.y.z the fix for A?" and "Have Debian version of package foo, version x.y.z the feature B?". -- Eugene V. Lyubimkin aka JackYF signature.asc Description: OpenPGP digital signature
Re: Proposal: user-visible list of divergences from upstream
On Tue, 2008-09-09 at 14:57 +0300, Eugene V. Lyubimkin wrote: > > BTS and online changelogs linked from the PTS ? > For upstream, for Debian people - enough. My proposal is to make > user-oriented list. Long changelog entries with some inner packaging > info and other stuff and viewing dozen of patches (even with good > comments) imho, is not what user have to do to answer on the simple > questions "Have Debian version of package foo, version x.y.z the fix for > A?" and "Have Debian version of package foo, version x.y.z the feature B?". Without some form of coordination between all the different bug trackers, this will never be possible. Security bugs have a long-standing mechanism for identifying specific issues and therefore specific fixes across distributions. Other bugs do not - different users report the same issue in different ways. *IF* the bug is forwarded upstream, then the upstream bug tracker reference is probably sufficient but that works best for upstream (who know which patterns to try and find), not users. In essence, your request comes down to: How does a user decide if the fix for issue A in Distro X is equivalent to the fix for issue B in Distro Y? I see no particular solution to that other than knowing how each distro records upstream bug references. Even then, you need upstream to be on-the-ball in marking bugs as duplicates or merged. The question is far from simple. It works for security bugs because a lot of people ensure that it works - doing it for other issues will require as much, if not more, work. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Proposal: user-visible list of divergences from upstream
"Eugene V. Lyubimkin" <[EMAIL PROTECTED]> writes: > Ben Finney wrote: > > "Eugene V. Lyubimkin" <[EMAIL PROTECTED]> writes: > > > >> Many of Debian packages have a patches that fixes some important > >> bugs which have not accepted by upstream for some reasons, some > >> of them also contains improvements, Debian-specific or not. > > […] > > > >> But how can users know about this changes in Debian packages? > > > > By the existing README.Debian and NEWS.Debian conventions (for > > persistent and version-sensitive changes, respectively). > > > Have non-Debian users access to this files? Sure. One doesn't need to use Debian to get a Debian source package — or even a Debian binary package. Both types contain these files. > Have Debian users access to these files when packages are not > installed on system? Only by getting the package and unpacking it (as I'm sure you know, the package can be unpacked and inspected without installing it). Are you proposing that, in addition to the changelog and the README.Debian and the NEWS.Debian and the package control files, that there should be *yet another* place where the package maintainer is expected to duplicate information on what they've done to the package? -- \ “Following fashion and the status quo is easy. Thinking about | `\your users' lives and creating something practical is much | _o__)harder.” —Ryan Singer, 2008-07-09 | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: user-visible list of divergences from upstream
Ben Finney wrote: > "Eugene V. Lyubimkin" <[EMAIL PROTECTED]> writes: [snip] But how can users know about this changes in Debian packages? >>> By the existing README.Debian and NEWS.Debian conventions (for >>> persistent and version-sensitive changes, respectively). >>> >> Have non-Debian users access to this files? > > Sure. One doesn't need to use Debian to get a Debian source package — > or even a Debian binary package. Both types contain these files. >> Have Debian users access to these files when packages are not >> installed on system? > > Only by getting the package and unpacking it (as I'm sure you know, > the package can be unpacked and inspected without installing it). Both these methods require: 1) knowledge about where to look for Debian changes (Debian users should know about README.Debian, but non-Debian?) 2) downloading some stuff Ok for geeks and developers, but too expensive for others, imho. > Are you proposing that, in addition to the changelog and the > README.Debian and the NEWS.Debian and the package control files, that > there should be *yet another* place where the package maintainer is > expected to duplicate information on what they've done to the package? README.Debian contains notes about important changes that made in Debian's variant of package for a long time of package' lifecycle. NEWS.Debian is especially good for upgrading. Changelog is for developers and geek users as it contains developer stuff. Patches is almost purely developer stuff. In my view, all these files do not cover "actual user-oriented important divergences from upstream". Only in my view. I understand that this proposed info will interfere with above mentioned one in Debian documentation files and will require some additional time to maintain. -- Eugene V. Lyubimkin aka JackYF signature.asc Description: OpenPGP digital signature
Re: Proposal: user-visible list of divergences from upstream
Neil Williams wrote: > On Tue, 2008-09-09 at 14:57 +0300, Eugene V. Lyubimkin wrote: >>> BTS and online changelogs linked from the PTS ? >> For upstream, for Debian people - enough. My proposal is to make >> user-oriented list. Long changelog entries with some inner packaging >> info and other stuff and viewing dozen of patches (even with good >> comments) imho, is not what user have to do to answer on the simple >> questions "Have Debian version of package foo, version x.y.z the fix for >> A?" and "Have Debian version of package foo, version x.y.z the feature B?". > > Without some form of coordination between all the different bug > trackers, this will never be possible. Security bugs have a > long-standing mechanism for identifying specific issues and therefore > specific fixes across distributions. Other bugs do not - different users > report the same issue in different ways. *IF* the bug is forwarded > upstream, then the upstream bug tracker reference is probably sufficient > but that works best for upstream (who know which patterns to try and > find), not users. > > In essence, your request comes down to: > > How does a user decide if the fix for issue A in Distro X is equivalent > to the fix for issue B in Distro Y? I see no particular solution to that > other than knowing how each distro records upstream bug references. Even > then, you need upstream to be on-the-ball in marking bugs as duplicates > or merged. > > The question is far from simple. > > It works for security bugs because a lot of people ensure that it works > - doing it for other issues will require as much, if not more, work. > Thanks a lot for your answer. I've understood that at least some coordination is needed, and this coordination will cost additional human resources. Though, I would be glad to see the proposed feature in some future. -- Eugene V. Lyubimkin aka JackYF signature.asc Description: OpenPGP digital signature
Re: Proposal: user-visible list of divergences from upstream
"Eugene V. Lyubimkin" <[EMAIL PROTECTED]> writes: > (suppose) I'm a system administrator. I have received new production > mail server. My only choice is a stable well-maintained distribution. > Last release for RedHat contains exim 1.5.19, and Debian version is > 1.5.18. I know about recently found security bug in 1.5.18. What > distribution I will choose without official acknowledge that Debian's > source for 1.5.18 already have a backported fix for bug? Okay, so now we're coming closer to the (your?) problem: you want official sanctioning/listing of patches added to a package. This is something that we (as in Debian Package Maintainer's) currently don't. What kind of "official acknowledgements" would suit your needs? I assume you don't want an DSA-like announcement of every patch included in a package. Following your arguments reading changelog seems to be to much effort for you as well. You seem to demand that maintainers spend extra time in deciding what patches should be "officially acknowledged" in the package so that system administrators can compare packages across distributions? I don't think that proposal would suit here well. A system administrator is unlikely to download/install a debian package just to find out what (possibly documented or undocumented) patches it contains. More likely they will want to look at some website aggregating that information. And here patch-tracking.debian.net comes pretty close, I think. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: user-visible list of divergences from upstream
"Eugene V. Lyubimkin" <[EMAIL PROTECTED]> writes: > Ben Finney wrote: > > Are you proposing that, in addition to the changelog and the > > README.Debian and the NEWS.Debian and the package control files, > > that there should be *yet another* place where the package > > maintainer is expected to duplicate information on what they've > > done to the package? > README.Debian contains notes about important changes that made in > Debian's variant of package for a long time of package' lifecycle. > NEWS.Debian is especially good for upgrading. Changelog is for > developers and geek users as it contains developer stuff. Patches is > almost purely developer stuff. In my view, all these files do not > cover "actual user-oriented important divergences from upstream". > Only in my view. Thanks for expressing this view. > I understand that this proposed info will interfere with above > mentioned one in Debian documentation files and will require some > additional time to maintain. To be clear: The time to maintain extra repositories of information is only one issue, and a relatively simple one to overcome. The greater issue is that such duplication of information invariably leads to multiple repositories with conflicting information. That situation is arguably *worse* for the person seeking knowledge than if the information were never recorded. The information about Debian-specific packaging changes already has numerous places to store that information. Any increase in the disparate information repositories needs to be demonstrated more valuable, not only than the extra time needed for maintaining them, but also than the *negative* value to everyone when those repositories conflict in what information they contain. -- \ Lucifer: “Just sign the Contract, sir, and the Piano is yours.” | `\ Ray: “Sheesh! This is long! Mind if I sign it now and read it | _o__)later?” —http://www.achewood.com/ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#498380: RFC: Implementing dpkg-vendor and adding vendor handling to dpkg-dev
Package: dpkg
Version: 1.14.24
Severity: wishlist
Tags: patch
Hi,
during the emDebian meeting in Extremadura we discussed the DEB_VENDOR
variable and how we could make good use of it for emDebian
packages. While discussing it we noticed that DEB_VENDOR, CFLAGS,
CXXFLGAS, LDFLAGS,... will only be set when dpkg-buildpackage is used
but not when debian/rules is invoked directly. Bug #498355 fixes this
for Lenny (to be used by backports from squeeze) and this bug extends
it to full functionality.
Below are the notes from the emDebian work session and attached a
patch for dpkg with a proof-of-concept implementation. Use cases are
described in the notes.
Note that the patch uses the existing /etc/dpkg/origins/ while the
work session uses /usr/share/vendor/ as they are not realy user/admin
configurable files but purely set by the distribution. It also does
not include the "vendor-handling" package.
MfG
Goswin
==
DEB_VENDOR as an alternative to the patch repository
Currently, emdebian has a massive repository of patches against Debian
packages. We would like to fold these back into Debian proper, without
changing the packages for Debian, so we need a way for a package build
to determine that we are building for emdebian (the same method could
be used for Ubuntu).
A wishlist bug for a new variable DEB_VARIANT has been filed against
dpkg-dev some time ago, and has just been accepted (with the name
DEB_VENDOR, which is fine for us) into squeeze's dpkg. While this was
not a requirement for emdebian (as our packages are cross-built, so we
never use the fact that DEB_VENDOR has a host distribution specific
default), it provides us with a standardized interface (for example,
Ubuntu could now use DEB_VENDOR == ubuntu to select the gcc SSP patch
they currently apply when /etc/debian_version says "Ubuntu". This
would allow us to build a "cross" toolchain targetting Ubuntu on
Debian, or vice versa).
There is general consensus that there should be some form of
"inheritance" relationship between vendors (emdebian derives from
Debian, individual hardware vendors derive from emdebian), and that a
package that has not been specialized for a particular vendor should
fall back to the closest "parent" vendor's behaviour.
The hierarchical "vendor" name space is not generally useful for
controlling package builds, so a middle layer is introduced that
converts the single vendor name into a set of build options in a flat
name space; the debian/rules file is responsible for doing this
resolution. On irc Raphael Hertzog suggested to provide a Makefile in
dpkg-dev and include that in debian/rules. The dpkg-dev Makefile could
then do
DEB_VENDOR?= $(shell dpkg-vendor -qDEB_VENDOR)
DEB_BUILD_OPTIONS ?= $(shell dpkg-vendor -qDEB_BUILD_OPTIONS)
cdbs, debhelper and the like could outomatically include that.
The reason why we require debian/rules to take some action instead of
relying on dpkg-buildpackage is that we can not rely on
dpkg-buildpackage to be used to build. Way too many users invoke
debian/rules directly and that should result in the same
result as via dpkg-buildpackage and higher level tools.
If DEB_VENDOR is empty, "debian" is assumed; if DEB_BUILD_OPTIONS is
empty, Debian policy is assumed (this keeps the current concept of
DEB_BUILD_OPTIONS overriding policy).
The proposed interface would be the "dpkg-vendor" program, used
directly or indirectly by including the Makefile fragment from
dpkg-dev, would be:
dpkg-vendor -q queries a variable. If the variable is
set in the environment, the current value is returned, otherwise the
value is deduced from other variables that are set or the default for
the current vendor.
As the build options might be dependent on the actual package, the
query for them should be invoked in the top level of a source
package. If called outside (debian/control does not exist), a warning
is printed to stderr and the "generic" options for the vendor
returned; querying DEB_VENDOR is always possible.
dpkg-vendor {-p|--parent} queries whether the current vendor
has a "parent" of or the vendor itself. The return code is 0
(yes) or 1 (no).
dpkg-vendor {-i|--is} queries whether the current vendor is
the same as .
A compliant implementation could add a dependency "vendor-handling" to
dpkg-dev, which provides a single file /usr/share/vendors/current that
specifies the "current" vendor.
The "vendor-handling" package is built by each vendor (Build-Options:
*), and the implementation provided by Debian copies the DEB_VENDOR
variable provided to the build into this file and makes the package
depend on "vendor-$(DEB_VENDOR)". That way the package can be
recompiled without source changes by every vendor. The reason this
should not be in e.g. base-files is that the sources that have to be
recompiled by every vendor should be minimal. A
Re: [Pkg-kde-extras] Bug#498263: kaffeine: please provide debian/README.source
Le Tue, Sep 09, 2008 at 12:50:23PM +1000, Mark Purcell a écrit : > > debian-devel, is there a view, does one need README.source if you > provide a patch target and use one of the standard patch management > systems? Seems like this would cover 90% of use cases and add very > little value! Hi Mark, I am getting more an more interested in README.source. There are many different work styles in Debian, and some developpers definitely do not want to contact the maintainers before pushing NMUs. I am now trying to use README.source to provide them guidelines about our packaging workflow. The text is not fixed yet but here is its latest version: This package uses quilt to patch the sources. Please refer to /usr/share/doc/quilt/README.source for more informations. This package is maintained by the Debian Med packaging team. Please refer to our group policy if you would like to commit to our Subversion repository. All Debian developpers have write acces to it. http://debian-med.alioth.debian.org/docs/policy.html It is not a big work to cut-and-paste, and hopefully can not be harmful, so even if the prospect of being useful is very low, I hope that it is not wasted effort. Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: user-visible list of divergences from upstream
On Tue,09.Sep.08, 15:53:16, Eugene V. Lyubimkin wrote: [...] > README.Debian contains notes about important changes that made in > Debian's variant of package for a long time of package' lifecycle. > NEWS.Debian is especially good for upgrading. Changelog is for > developers and geek users as it contains developer stuff. Patches is > almost purely developer stuff. In my view, all these files do not cover > "actual user-oriented important divergences from upstream". Only in my > view. I understand that this proposed info will interfere with above > mentioned one in Debian documentation files and will require some > additional time to maintain. I think having README.Debian and NEWS.Debian easily accessible on packages.d.o would be a progress. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: [Fwd: Re: Debian Live Lenny Beta1]
David López Zajara (Er_Maqui) wrote: > I've tested the lenny live CD on MBP (SantaRosa model),and i have this > problem. I'm booting with rEFIt. sorry for the late answer: the problem is know, and already fixed. expect newer builds with a fixed syslinux version soon. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: user-visible list of divergences from upstream
Andrei Popescu wrote: > On Tue,09.Sep.08, 15:53:16, Eugene V. Lyubimkin wrote: > > [...] > >> README.Debian contains notes about important changes that made in >> Debian's variant of package for a long time of package' lifecycle. >> NEWS.Debian is especially good for upgrading. Changelog is for >> developers and geek users as it contains developer stuff. Patches is >> almost purely developer stuff. In my view, all these files do not cover >> "actual user-oriented important divergences from upstream". Only in my >> view. I understand that this proposed info will interfere with above >> mentioned one in Debian documentation files and will require some >> additional time to maintain. > > I think having README.Debian and NEWS.Debian easily accessible on > packages.d.o would be a progress. Not sure about NEWS.Debian, but for README.Debian I think so too. -- Eugene V. Lyubimkin aka JackYF, Ukrainian C++ developer. signature.asc Description: OpenPGP digital signature
Re: Proposal: user-visible list of divergences from upstream
On Tuesday 09 September 2008 14:53:16 Eugene V. Lyubimkin wrote: > Ben Finney wrote: [snip] > > Only by getting the package and unpacking it (as I'm sure you know, > > the package can be unpacked and inspected without installing it). > > Both these methods require: > 1) knowledge about where to look for Debian changes (Debian users should > know about README.Debian, but non-Debian?) > 2) downloading some stuff > > Ok for geeks and developers, but too expensive for others, imho. I failed to see how adding an extra file you are suggesting (debian/divergences or whatever) could be better than already exising ones like README.[Debian|source] - it is basically in the same boat with regard to above mentioned requirements. OTOH, it is more reasonable to maintain well documented patches using their headings (note, the single place to change), which could then be extracted and revealed by patch-tracking.debian.net or whereever. I doubt there is anything more direct and easier for regular users, since they would read exactly what has been documented in the relevant patch created by the developer, and would need only a www browser or text editor, where the developer would has a single place to worry about. > > Are you proposing that, in addition to the changelog and the > > README.Debian and the NEWS.Debian and the package control files, that > > there should be *yet another* place where the package maintainer is > > expected to duplicate information on what they've done to the package? > > README.Debian contains notes about important changes that made in > Debian's variant of package for a long time of package' lifecycle. > NEWS.Debian is especially good for upgrading. Changelog is for > developers and geek users as it contains developer stuff. Patches is > almost purely developer stuff. In my view, all these files do not cover > "actual user-oriented important divergences from upstream". Only in my > view. I understand that this proposed info will interfere with above > mentioned one in Debian documentation files and will require some > additional time to maintain. I believe that such data duplication would surely lead to discrepancies at some point, which would add even more confision to the reader. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#498396: ITP: argyll -- ICC compatible color management system
Package: wnpp Owner: Roland Mas <[EMAIL PROTECTED]> Severity: wishlist * Package name: argyll Version : 1.0.3 Upstream Author : Graeme Gill <[EMAIL PROTECTED]> * URL or Web page : http://www.argyllcms.com/ * License : GPLv3 Description : ICC compatible color management system For reasons lost in the mists of time, ArgyllCMS is only in Christian Marillat's Debian-Multimedia repository. A quick glance through the sources don't show any licensing problems, so I think it would be a good addition to Debian main. I'll most probably use the current packaging as a base for the first upload to Debian, although it may evolve as time passes. Roland. -- Roland Mas In every life you got some trouble, when you worry you make it double. -- in Don't worry, be happy (Bobby McFerrin) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
