Your message dated Fri, 11 Aug 2017 12:44:51 -0700 with message-id <87o9rlx51o....@iris.silentflame.com> and subject line Closing inactive Policy bugs has caused the Debian Bug report #704233, regarding Policy for local packages. to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 704233: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704233 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: debian-policy Severity: wishlist Le Mon, Jan 21, 2013 at 09:52:06PM +0100, Wouter Verhelst a écrit : > > Debian's policy document, and many of Debian's tools, assume that any > built Debian package is always intended for upload into Debian proper, > or at least for wide distribution. This isn't always true; and for > people who wish to make internal-use-only packages, this makes it much > harder to figure out which part of the documentation is relevant for > them and which part isn't. Hi Wouter, sorry for the lack of answer. As explained by Russ on email@example.com, we have a big backlog and a not much manpower. But in any case, please do not hesitate filing bug reports for your suggestions. Observing the work done in the past year, I would say that it roughly consists in a few large modifications seasonned with low-hanging fruits. The next large modifications we plan are the documentation of triggers and multiarch, and then a major restructuration which will be the opportunity to switch to DocBook XML. People more interested in the idea you propose are of course welcome to focus on it. A lot of preparatory work is needed anyway. I am creating an entry in the BTS to keep track. For convenience, I keep the rest of your original email cited below. Have a nice week-end, -- Charles > > Let me explain what I'm on about here. > > There are several things in policy which are technical requirements or > expectations that other parts of the Debian infrastructure expect > packages to abide by. For instance, the bits in policy which specify > that library packages should provide either a shlibdeps or a symbols > file are technical in nature; providing library packages which don't do > such a thing will make it harder to build proper packages which use > these libraries, since dpkg-shlibdeps won't find them. Similarly, the > fact that we have a short dependency and a long dependency, and that > these are not related and should be considered as two distinct things, > is a technical requirement. > > At the same time, some of the requirements in policy are things that we > really really want for packages uploaded to Debian, and that people > should probably abide by if they produce a package for wide > distribution, but aren't very critical for packages that are intended > for internal use only. For instance, if you have a local policy that > says your webapps should be installed to a particular directory under > /opt, then it makes perfect sense (and will probably not break anything) > if your packages install your webapps into /opt rather than somewhere > under /usr/share. Similarly, if you have a local QA team which vets a > particular compiled version of a binary, and your local policy forbids > ever recompiling any QA-vetted binaries for mere packaging (instead, > your scripts must build RPM, Windows, MacOS, and Debian packages from > the same compiled java binary), then it's probably perfectly fine to > have a debian/rules which doesn't compile anything, but instead just > copies the already-compiled binaries into place. > > Obviously you wouldn't want to distribute those packages anywhere, but > that doesn't mean it's a bad idea to make them if that makes your life > easier. > > Occasionally, these latter two were actual requirements at the customer > where I was giving that course last week. > > Also, the fact that policy mixes these two kinds of requirements into > one document has caused some people to ignore it, with all > consequences thereof. > > I think it would make sense to document which parts of policy fall in > the "technical requirements and/or expectations" category, and which > parts don't. This would allow people to understand how to build a simple > local package, without having to filter out the information that (to > them) is irrelevant anyway. > > Thoughts? > >  see, for instance, <https://github.com/jordansissel/fpm>, and > especially the speaker notes on slide 18 in the presentation that's > linked from there. > > -- > Copyshops should do vouchers. So that next time some bureaucracy requires you > to mail a form in triplicate, you can mail it just once, add a voucher, and > save on postage. > > > -- > 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/20130121205206.gb29...@grep.be
--- End Message ---
--- Begin Message ---control: user debian-pol...@packages.debian.org control: usertag -1 +obsolete control: tag -1 +wontfix Russ Allbery and I did a round of in-person bug triage at DebConf17 and we are closing this bug as inactive. The reasons for closing fall into the following categories, from most frequent to least frequent: - issue is appropriate for Policy, there is a consensus on how to fix the problem, but preparing the patch is very time-consuming and no-one has volunteered to do it, and we do not judge the issue to be important enough to keep an open bug around; - issue is appropriate for Policy but there does not yet exist a consensus on what should change, and no recent discussion. A fresh discussion might allow us to reach consensus, and the messages in the old bug are unlikely to help very much; or - issue is not appropriate for Policy. If you feel this bug is still relevant and want to restart the discussion, you can re-open the bug. However, please consider instead opening a new bug with a message that summarises and condenses the previous discussion, updates the report for the current state of Debian, and makes clear exactly what you think should change. A lot of these old bugs have long side tangents and numerous messages, and that old discussion is not necessarily helpful for figuring out what Debian Policy should say today. -- Sean Whitton
Description: PGP signature
--- End Message ---