[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#704233: marked as done (Policy for local packages.)

Your message dated Fri, 11 Aug 2017 12:44:51 -0700
with message-id <87o9rlx51o.fsf@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 owner@bugs.debian.org
immediately.)


-- 
704233: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704233
Debian Bug Tracking System
Contact owner@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 debian-vote@l.d.o, 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[1], 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?
> 
> [1] 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-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: http://lists.debian.org/20130121205206.GB29049@grep.be

--- End Message ---
--- Begin Message --- 
control: user debian-policy@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

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: