Bug#681289: debian-policy: Changelog and copyright should be package metadata
Hi,
* Raphaël Hertzog hert...@debian.org [2012-07-12 08:46:03 CEST]:
Both the changelog and the copyright files are stored with a package's
normal data (within data.tar in the .deb) but they are really package
metadata (that should be part of control.tar in the .deb).
Are they? I consider them documentation and expect them be next to the
documentation.
All the tools and services that currently extract both of those files
(packages.d.o, apt-listhanges, etc.) would benefit from being able to
extract them with the rest of the package metadata.
No, please don't use packages.d.o as a reasoning without having talked
to the packages.d.o maintainers. This is also the reason why I tend to
close your bugreport against packages.d.o because the plan is to not
extract them anymore. ftpmasters/dak are extracting them already and
providing them to us, so the packages.d.o site will *not* extract this
information in the future.
And without any more than that statement I'm not really buying that it
really would be a benefit?
Additionnaly it also solves a problem that we have with multi-arch same
packages and bin-nmu. Such a bin-nmu means that the changelog on the
bin-nmued architecture will be different from the other arches and the
package is thus no longer co-installable.
That might be the real issue, please don't push other reasonings to
front without contacting the people involved there whether this is
really the case.
2/ that programs that want to retrieve the changelog and/or copyright file
of an installed package should try to use dpkg-query --control-show pkg
changelog|copyrigh and fall back to the usual path if that fails.
Those interfaces are available in wheezy's dpkg (= 1.16.5).
So that would force services to upgrade to wheezy as soon as the first
such package lands in unstable, right?
3/ that programs that want to retrieve the changelog and/or copyright file
of a .deb file should use dpkg-deb -I file changelog|copyrigh (or
look for the changelog/copyright file in the directory extracted
with dpkg-deb -e file)
that programs are also end-users, not? Users expect the copyright
and changelog information to be readily available to them. How do you
address their expectations? Will they be in
/var/lib/dpkg/info/package.{changelog,copyright}, so a symlink could
help with that?
Is there any other solution that would help the multiarch issue
instead?
Did I miss a thread on debian-devel about this?
Last thing: policy is about document current practises, not about
future possibilities. Doesn't this bugreport come a bit early?
Thanks,
Rhonda
--
Fühlst du dich mutlos, fass endlich Mut, los |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120712150946.ga14...@anguilla.debian.or.at
Re: Bug#681289: debian-policy: Changelog and copyright should be package metadata
* Thomas Preud'homme robo...@celest.fr [2012-07-12 17:59:19 CEST]: Le jeudi 12 juillet 2012 17:09:46, Gerfried Fuchs a écrit : Did I miss a thread on debian-devel about this? There was a thread indeed. See this one: http://lists.debian.org/debian-release/2012/06/msg00232.html Well, that's debian-release, not debian-devel. Thanks for the pointer though! Enjoy, Rhonda -- Fühlst du dich mutlos, fass endlich Mut, los | Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden Fühlst du dich machtlos, geh raus und mach, los | 23.55: Alles auf Anfang Fühlst du dich haltlos, such Halt und lass los| -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120712161645.ga17...@anguilla.debian.or.at
alternative dependency ordering - with respect of packages in main
Hi! Policy is clear on packages in main aren't allowed to depend on packages outside of main. Now in a fair amount of cases this has been worked around by having the package outside of main as alternative dependency and a package in main offer basic functionality for the package to still be able to work. I know that the buildd system likes to pull in the first package in such an alternative dependency chain. And now I start to wonder: Is it allowed for a package in main to have a package _outside_ of main as first component of an alternative dependency? The package in question is extremely unlikely to ever be used as Build-Depends, so this is of a more general question. What also might be used as argument is the social contract, DFSG #4: Our priorities are our users and free software -- it can be argued that we don't put the priority on free software in such a case. tl;dr - what do you think, is a Depends: foo-contrib | foo acceptable for packages in main or should it be Depends: foo | foo-contrib instead? Thanks for answering to the short strawpoll, Rhonda -- Fühlst du dich mutlos, fass endlich Mut, los | Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden Fühlst du dich machtlos, geh raus und mach, los | 23.55: Alles auf Anfang Fühlst du dich haltlos, such Halt und lass los| -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110920111237.ga24...@anguilla.debian.or.at
[patch] experimental and uploads to unstable
Hi! I just found this part in the devref which should get removed since version tracking in the BTS is in place. Find the patch attached, as per README-contrib I'm not commiting it myself, at least not until I'm told so. ;) Enjoy! Rhonda -- dholbach Last day of https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in 34 minutes in #ubuntu-classroom on irc.feenode.net * ScottK hands dholbach an r. Rhonda Are they fundraising again? Index: resources.dbk === --- resources.dbk (Revision 7825) +++ resources.dbk (Arbeitskopie) @@ -753,12 +753,6 @@ An alternative to literalexperimental/literal is to use your personal web space on literalpeople.debian.org/literal. /para -para -When uploading to literalunstable/literal a package which had bugs fixed -in literalexperimental/literal, please consider using the option -literal-v/literal to commanddpkg-buildpackage/command to finally get -them closed. -/para /section /section
Bug#536790: debian-policy: please clarify 'required target' in section 4.9
* Jamie Strandboge ja...@ubuntu.com [2009-07-13 16:39:43 CEST]: Section 4.9 of http://www.debian.org/doc/debian-policy/ch-source.html states that there a number of required targets for debian/rules. Specifically: This file must be an executable makefile, and contains the package-specific recipes for compiling the package and building binary package(s) from the source. At a minimum, required targets are the ones called by dpkg-buildpackage, namely, clean, binary, binary-arch, binary-indep, and build. If the policy is to be read very strictly, then all of the required targets must be present in debian/rules, That's wrong reading, it doesn't claim so. It has to contain the recipes - but it doesn't claim that they have to be in there directly. If you do a s/present/implemented/ you might be able to follow. :) For someone new to CDBS, debhleper 7, or any other existing or future package helper, the reader of policy must either ignore the violations from this strict reading or relax the interpretation of policy in such a way to infer that helper programs provide these targets even though they are not explicitly listed. This is ambiguous. This are the required targets that debian/rules has to implement and to be working. A specific example occurred recently when reviewing a package with a debian/rules file similar to /usr/share/doc/debhelper/examples/rules.tiny and running an older lintian on it. Lintian complained about the ^ targets, so policy was consulted, and a strict reading shows that the rules file was in violation of policy. A discussion ensued and quite a bit of developer time was lost. Well, older lintian version surely also complain about other things that are in full compliance with both current practices and policy. That's why it switched to use debian/rules -n $target for tests these days. Using an older and buggy version of lintian is quite an interesting argumentation line if you ask me. lintian never claimed to be perfect nor is this one of its target aims. Adding something like the following would greatly reduce the ambiguity of section 4.9: A required target is one that is either explicitly listed in debian/rules or supplied by a helper program. Why does it have to be a helper program and not be allowed to be any other means? This is just as ambigious as you claim it to be currently. Just my thoughts, Rhonda -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Relative and absolute symlinks
* Manoj Srivastava [EMAIL PROTECTED] [2008-08-27 16:57:58 CEST]: Do we have consensus that a: a) links that do not climb directory trees should be encouraged to be relative (do not break case 2) b) subdirectories of /var/*/ and /usr/* should be treated as top level directories for the purposes of the relative/absolute symlink rule: any links that climbs out of /usr/foo/bar or /var/foo/bar should be absolute, and the rest of the current rule stays in place? That would totally be along the lines that I thought and I'm glad that others think the idea makes sense, too. Thanks. :) Rhonda -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Relative and absolute symlinks
* Lionel Elie Mamane [EMAIL PROTECTED] [2008-08-15 16:47:41 CEST]: (Further discussion should happen on [EMAIL PROTECTED], but please CC me.) Same with me, I plan to scan the archives of the list, but am not subscribed. During Manoj's policy talk at DebConf8, Gerfried opened the subject of the policy's stand on relative and absolute symlinks, which currently is absolute if going through top-level, relative otherwise. I wanted to give another data-point: Mailman switched its intra-/var/ symlinks to be absolute, because relative symlinks there broke setups of people that moved their /var/lib/mailman/ directory to another partition, not through mounting, but through replacing their /var/lib/mailman/ directory by a symlink to elsewhere - e.g. /u/mailman . This broke e.g. relative symlinks /var/lib/mailman/log to ../../logs/mailman. Bugs #413604 and #408855 contain the whole story. The story was raised for me by different users of the wesnoth package. People seem to move at least their /usr/games section to some other place and symlink it because of its size. I also am aware that there are people doing the same for /var/spool. In general my suggestion was to at least allow /usr/* and /var/* symlinks to be absolute between different hierarchies in there instead of putting the weight of a should in there. Rationale being that the structure within /usr and /var is quite split up and it does make sense to allow people to do the same stuff with direct root directories without any pains. I must say I don't quite see in what scenario relative symlinks make something work that absolute symlinks do not make work. So, is there any reason at all to use relative symlinks? Quite some times I experienced them to be more pain than gain, too. It might be useful if people shift around complete hierarchies, but we are not really speaking of package-internal symlinks here usually. Thanks, Rhonda -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444270: debian-policy: policy doesn't say anything on ~ in Version numbers
Package: debian-policy Version: 3.7.2.2 Severity: normal Hi! It would be kind if in section 5.6.12. `Version' the usage of ~ could be noted, at least saying that it is an allowed character, too. Currently every package with a ~ in its version (either upstream or debian part of it) is violating the policy in that respect. So long, Rhonda -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
