Bug#801065: Documenting how to not fail postinst on service fails to start
On Wed, Feb 15, 2023 at 02:38:10PM -0500, Marvin Renich wrote:
> > > > - the service fails to start in the postinst.
>
> This implies that "the service is running" is part of "the service is
> configured", which is where I disagree.
What Steve said is that if
- The service fails to start, *AND*
- The service was previously running (or this is a new install)
*THEN*
this is something that should make postinst fail.
The two preconditions are linked, and should not be looked at
separately.
If the service was *not* previously running, then that is a different
situation.
But if the service was previously running and now a restart fails, then
obviously[1] this is a problem with the upgrade that should be looked at
by the admin, which means it must be flagged to the admin somehow.
As I mentioned in the TC discussion, one can reasonably debate what the
best way is to flag such problems, but I think it's not reasonable to
say "let's just push it under the mat, it doesn't matter".
We currently only have one sure way of telling the admin that there is a
problem, and that is "fail postinst".
As such, I think any suggestion that we ignore a restart failure of a
service that was running before the dpkg run should be accompanied by a
plan on *how* to flag this failure to the admin in a way that the admin
will know that things failed. In the absence of that, the status quo of
"postinst should fail on a restart of a service" should probably be
retained.
[1] barring extreme corner cases of the style "the admin made broken
changes but forgot to try a restart"
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1026231: debian-policy: document droppage of support for legacy locales
On Fri, Jan 20, 2023 at 05:16:43PM +, Simon McVittie wrote:
> On Fri, 20 Jan 2023 at 09:54:21 -0700, Anthony Fok wrote:
> > supposedly some older Chinese websites are still using "GBK" as
> > encoding, probably something like:
> >
> >
> >
> > which has less than 30,000 characters and thus a very limited subset
> > of Unicode. And, presumably not everyone has the know how to convert
> > to UTF-8, the Chinese government wants those unable to at least change
> > that meta tag to:
> >
> >
>
> Sure, but neither of those actually require us to support GBK or GB
> 18030 as a system locale, only as something that iconv() (or whatever
> browsers actually use, which is probably their own thing) can convert
> into their preferred internal representation (which is almost certainly
> UTF-8, UTF-16 or UCS-4).
Those files need to be edited *somewhere*. If that somewhere is a Debian
desktop, then you also need editors that know how to write such files,
etc.
Sometimes it's just easier if the whole thing uses the same encoding.
> Analogously, we've never supported using Windows-1252 (Microsoft's
> legacy Latin-1 variant) as a system locale encoding in some hypothetical
> locale like en_US.windows-1252, but HTML documents with
> text/html;charset=windows-1252 still work fine.
Windows-* encodings were native on Windows, and we only needed to
be able to read files that were generated on such systems.
We're talking here instead about a government-mandated encoding that
systems are expected to support; not only to consume data, but also to
*produce* data.
Windows-* encodings never had that attached to them.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1026231: debian-policy: document droppage of support for legacy locales
On Thu, Jan 19, 2023 at 11:47:42AM +, Simon McVittie wrote:
> Preferring to use Unicode does seem to be the direction that all of
> computing is going in, as a simplifying assumption - for example W3C
> advice for HTML is "You should always use the UTF-8 character encoding"[1]
> - and as we know, things that aren't tested usually don't work. So I
> think the level of functionality for non-UTF-8 locales and encodings in
> the software we package is going to decline over time, whether Debian
> wants it to or not.
If the world's most populous country uses something that is not UTF-8, I
think it's safe to say it's being tested, if only by people who will
file bugs when things go awry.
If the PRC government *requires* a non-UTF-8 encoding for things sold to
them, we would be doing our users who want to sell a product containing
Debian to the PRC government a disservice by dropping support for it
altogether.
We don't have to ensure it works perfectly out of the box; just that
support is achievable with a reasonable amount of work.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#968226: Move documentation of Build-Depends alternative selection out of footnote
On Thu, Sep 22, 2022 at 07:11:38PM -0700, Russ Allbery wrote:
> Wouter Verhelst writes:
> > On Tue, Sep 20, 2022 at 07:17:17PM -0700, Russ Allbery wrote:
> >> Wouter Verhelst writes:
>
> >>> Thanks, yeah, I missed that. I'll have a stab at a patch some time soon
> >>> (probably after debconf though)
>
> >> Here, a couple of years later, is a patch that does this, and which I
> >> think is ready for seconds.
>
> > Whoops, sorry; this completely slipped my mind.
>
> Apologies, that probably sounded like I was complaining about you not
> sending a patch. I only meant to mention that this was a thread from a
> long time back, which is why it might seem out of the blue. I have
> dropped so many Policy balls that I'm certainly not going to complain
> about a bug slipping someone else's mind. :)
Oh no, trust me, it wasn't; but I still feel bad for having dropped the
ball, as I always do :-)
> > I think this could be expanded a bit?
>
> > "This is done to reduce the risk of inconsistencies between repeated
> > builds, in case a package is temporarily not available to be installed
> > on a given architecture (which due to the nature of the unstable
> > distribution might happen for any number of reasons) at the time of the
> > (re-)build of a package."
>
> > or something along those lines. The point is to make it clear how these
> > inconsistencies are caused, which I think will help with understanding.
>
> > (I realize your text is what the footnote originally said, but I think
> > this suggestion would improve matters)
>
> Here's an updated patch that expands that and also is more explicit, since
> I found my own wording a bit hard to read. I also added an example. It
> may be a bit verbose now, but this feels like an important topic to be
> clear about given how often it comes up.
>
> I also reworded the paragraph about backports to hopefully address
> Holger's reading. It's just trying to say that backports uses aptitude in
> the normal way and doesn't do anything special to transform the
> alternative.
I think that text is miles better, yes. Seconded.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
signature.asc
Description: PGP signature
Bug#968226: Move documentation of Build-Depends alternative selection out of footnote
On Sat, Sep 24, 2022 at 10:16:12AM +, Holger Levsen wrote:
> On Fri, Sep 23, 2022 at 04:17:04PM +0100, Simon McVittie wrote:
> > On Thu, 22 Sep 2022 at 19:11:38 -0700, Russ Allbery wrote:
> > > I also reworded the paragraph about backports to hopefully address
> > > Holger's reading. It's just trying to say that backports uses aptitude in
> > > the normal way and doesn't do anything special to transform the
> > > alternative.
>
> yup, it's better, thanks.
>
> > It's perhaps worth mentioning that experimental does something similar
> > (it has used the aptitude and aspcud resolvers at various times, but
> > I'm not sure which one is currently in use).
>
> I see.
>
> I think my biggest concern is actually not how it's described but rather
> why/that it is different at all (and then wondering whether it will stay
> that way...)
Experimental is different because it is an incomplete distribution,
which needs to default to using packages from unstable except if
build-depends explicitly lists versions that are only available in
experimental.
When I set up the first experimental autobuilder back in the day, I
hacked the sbuild resolver (it had its own resolver at the time) to
explicitly tell apt which packages to pull from experimental, rather
than doing something like "-t experimental" or some such.
I wrote
https://lists.debian.org/debian-devel-announce/2006/04/msg7.html to
-devel-announce at the time; but since I haven't been involved with
buildd work in a while, I can't really say whether it's still accurate
or relevant today.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#968226: Move documentation of Build-Depends alternative selection out of footnote
On Tue, Sep 20, 2022 at 07:17:17PM -0700, Russ Allbery wrote: > Wouter Verhelst writes: > > On Tue, Aug 11, 2020 at 10:05:42AM -0700, Russ Allbery wrote: > >> Wouter Verhelst writes: > > >>> -policy: this is a question that has come up before > >>> (https://lists.debian.org/debian-devel/2016/12/msg00470.html is > >>> another example that springs to mind, but I'm pretty sure there are > >>> more), so I think we should document in Policy that a) buildd only > >>> looks at the first dependency in alternative build-dependencies, and > >>> b) why this is the case. > > >> Policy already says: > > >> While Build-Depends, Build-Depends-Indep and Build-Depends-Arch > >> permit the use of alternative dependencies, these are not normally > >> used by the Debian autobuilders. To avoid inconsistency between > >> repeated builds of a package, the autobuilders will default to > >> selecting the first alternative, after reducing any > >> architecture-specific restrictions for the build architecture in > >> question. While this may limit the usefulness of alternatives in a > >> single release, they can still be used to provide flexibility in > >> building the same package across multiple distributions or > >> releases, where a particular dependency is met by differently named > >> packages. > > >> in 7.1. However, it's hidden in a footnote. Perhaps we should make it > >> more prominant (and make it clear that it's normative), and tweak the > >> wording. > > > Thanks, yeah, I missed that. I'll have a stab at a patch some time soon > > (probably after debconf though) > > Here, a couple of years later, is a patch that does this, and which I > think is ready for seconds. Whoops, sorry; this completely slipped my mind. > -- > Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/> > > From dd30c5455f13086dd0ef90bf6890c20729a1ac0b Mon Sep 17 00:00:00 2001 > From: Russ Allbery > Date: Tue, 20 Sep 2022 19:11:54 -0700 > Subject: [PATCH] Improve alternative build dependency discussion > > Alternatives in build dependencies are normally (except for > backports) handled specially by autobuilders to try to maintain > consistent builds. This was documented in Policy, but in a > footnote that people often didn't see. > > Move this text into the main body of the discussion of build > dependencies and reword it for additional clarity. Add a pointer > to this discussion where alternative dependencies are introduced. > --- > policy/ch-relationships.rst | 41 ++--- > 1 file changed, 25 insertions(+), 16 deletions(-) > > diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst > index 5074428..f177885 100644 > --- a/policy/ch-relationships.rst > +++ b/policy/ch-relationships.rst > @@ -15,7 +15,10 @@ control fields of the package, which declare dependencies > on other > packages, the package names listed may also include lists of alternative > package names, separated by vertical bar (pipe) symbols ``|``. In such a > case, that part of the dependency can be satisfied by any one of the > -alternative packages. [#]_ > +alternative packages. (Alternative dependencies in ``Build-Depends``, > +``Build-Depends-Indep``, and ``Build-Depends-Arch`` are normally used in a > +restricted way. See :ref:`Relationships between source and binary packages > +` for more details.) > > All of the fields may restrict their applicability to particular versions > of each named package. This is done in parentheses after each individual > @@ -620,6 +623,27 @@ earlier for binary packages) in order to invoke the > targets in > ``Build-Conflicts-Arch`` fields must be satisfied when these targets > are invoked. > > +Alternative dependencies are allowed in the ``Build-Depends``, > +``Build-Depends-Indep``, and ``Build-Depends-Arch`` fields, but Debian's > +autobuilders normally interpret them in a restricted way. After > +dependencies that do not apply to the current architecture are removed, > +all alternatives specifying different package names than the first > +alternative are dropped. (Alternatives specifying the same package name > +are kept to permit relationships such as ``foo (<= x) | foo (>= y)``.) > +The effect, therefore, is to use only the first alternative that is valid > +on the relevant architecture. This is done to reduce the risk of > +inconsistencies between repeated builds. I think this could be expanded a bit? "This is done to reduce the risk of inconsistencies betw
Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes
On Sun, Sep 18, 2022 at 06:01:38PM -0700, Russ Allbery wrote:
> Guillem Jover writes:
>
> > Oh! I've completely missed this all this time, I think because that
> > feels very weird given that it has no synopsis and the text is added
> > already on the first line on the spec. :/
>
> Other formatted fields with the same semantics are Source, Disclaimer, and
> Comment. I don't think there are any fields in debian control files with
> those semantics (Description is the only formatted field and it has a
> synopsis), but there are several of them in copyright files.
>
> Source is another ongoing minor problem, since it's *usually* a URL but is
> not required to be one, and sometimes a textual description of the source
> is needed. Here too, a structured format would have been nicer, so that
> you could have something like:
>
> source:
> urls:
> - https://example.com/foo
> - https://example.org/foo
> comment: >-
> The foo-rewrite script was originally posted to comp.unix.sources in
> 1992 but otherwise has no source other than the Debian package.
>
> Ah well.
>
> > Right, the problem I see is that applying this formatting to a field
> > that has no special treatment for the first line just after the field
> > name seems very unintuitive, because the first line does not contain an
> > additional prefixing space, or if it does no one is adding it!
>
> > It feels very weird to me that all these would be equivalent:
>
> > Copyright: Something long that might trigger some wrapping behavior
> > Other thing very long that might not be clear behaves as the above
> > More
>
> > and
>
> > Copyright: Something long that might trigger some wrapping behavior
> > Other thing very long that might not be clear behaves as the above
> > More
>
> > and
>
> > Copyright:
> > Something long that might trigger some wrapping behavior
> > Other thing very long that might not be clear behaves as the above
> > More
>
> I think my brain just assumes that all whitespace after the colon of a
> field name and before the first non-whitespace character is ignored, so
> doesn't have a problem with that, but I can see why it would be confusing.
>
> > Otherwise, if the current semantics are retained, at least for me, the
> > first line behavior really needs to be clarified.
>
> Yes, we should distinguish between formatted text with synopsis and
> formatted text without synopsis more clearly. Or, you know, just propose
> a new YAML format which would make it trivial to clean up all of these
> problems *and* would provide first-class editor support and easy parsing
> in every major programming language. :) But that's WAY bigger than this
> bug.
If we're going to do that, it might make sense to explicitly allow JSON
and/or TOML as alternative representations, because there are some
really weird edge cases in YAML.
> > If we end up switching the field semantics, that seems it might cause
> > unnecessary modification churn, given that I (not sure whether other
> > people have done this before than me as well) at least have "instigated"
> > unintentionally this type of change in several places (packages I
> > maintain, golang/prometheus team), including tooling (AFAIR dh-make and
> > dh-make-golang), and other people might have also picked this up too. :/
>
> I think making the field a line-based list is the obviously correct thing
> to do. It's just not backward-compatible, so we will have to face the
> question of how we handle a version bump in the copyright file (and of
> course figure out if we're going to deal with all of the other requests
> that would require a version bump).
I think semantic versioning would require you make this a major version
bump, since like you say it's not backwards compatible.
> And I have packages where individual copyright lines are longer than 80
> columns, so we either have to require unwrapped lines greater than 80
> columns (which I'd rather not do), or we have to define line wrapping
> semantics for line-based lists, which adds yet more irritating ugliness to
> the deb822 format. Probably just "if the line is indented by more than
> one space, it's a continuation for the previous line" I guess.
Ah yes, but then if you do that, the old examples in policy that were
being patched away here (usage of which might exist in the wild) would
now have different semantics...
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Re: Bug#991533: lintian: please forget about required-field Standards-Version for udeb packages
On Fri, Aug 13, 2021 at 09:43:32AM -0700, Felix Lechner wrote:
> Hi,
>
> On Fri, Aug 13, 2021 at 9:12 AM Bill Allombert wrote:
> >
> > Then I would suggest that a new lintian category is designed to catter
> > for such usage, so that tools might chose not to display such warnings
> > as they do with 'P: pedantic' currently.
>
> I am not sure that helps. The tag 'outdated-standards-version' does
> not offer solutions to an obscure but undisputed deficiency. It
> states: "You are too slow."
I disagree with this assessment.
I think it rather says "things have changed since you last looked at
this package, there might be more things that are relevant for you now".
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Bug#968226: Build-Depends-If-Available
On Tue, Aug 11, 2020 at 10:05:42AM -0700, Russ Allbery wrote: > Wouter Verhelst writes: > > > -policy: this is a question that has come up before > > (https://lists.debian.org/debian-devel/2016/12/msg00470.html is another > > example that springs to mind, but I'm pretty sure there are more), so I > > think we should document in Policy that a) buildd only looks at the > > first dependency in alternative build-dependencies, and b) why this is > > the case. > > Policy already says: > > While Build-Depends, Build-Depends-Indep and Build-Depends-Arch permit > the use of alternative dependencies, these are not normally used by > the Debian autobuilders. To avoid inconsistency between repeated > builds of a package, the autobuilders will default to selecting the > first alternative, after reducing any architecture-specific > restrictions for the build architecture in question. While this may > limit the usefulness of alternatives in a single release, they can > still be used to provide flexibility in building the same package > across multiple distributions or releases, where a particular > dependency is met by differently named packages. > > in 7.1. However, it's hidden in a footnote. Perhaps we should make it > more prominant (and make it clear that it's normative), and tweak the > wording. Thanks, yeah, I missed that. I'll have a stab at a patch some time soon (probably after debconf though) -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Bug#968226: Build-Depends-If-Available
Package: debian-policy On Sun, Aug 09, 2020 at 06:28:50PM +0100, Barak A. Pearlmutter wrote: > I understand what you're saying, and indeed trying to encode > "Build-Depends-If-Available: foo" as "Build-Depends: foo | something" > is a bad idea from the get-go. After all, foo can have three states on > an architecture: installable, unavailable, or > available-but-uninstallable-for-some-reason. And we want different > behaviour in the three cases: build with it, build without it, or > delay-building-until-installable. And we can't shoehorn those three > things into the binary logic of "foo | something". Exactly, and therein lies the problem. Buildd used to consider alternative build-dependencies, and it caused a never-ending stream of package transition entanglements, because the delay-building-until-installable thing never happened, which meant that every rebuild of something to solve a problem would have to either be timed very well, or would be likely to be playing a roulette game of "will the rebuild solve all problems or create yet even more". -policy: this is a question that has come up before (https://lists.debian.org/debian-devel/2016/12/msg00470.html is another example that springs to mind, but I'm pretty sure there are more), so I think we should document in Policy that a) buildd only looks at the first dependency in alternative build-dependencies, and b) why this is the case. Suggestion: ---8<--- Note that sbuild, the program which builds packages on each of Debian's architectures, only considers the first alternative for any declared element in the Build-Depends: header, after removing alternatives with architecture restrictions that don't apply to the architecture on which the package is building. All other alternatives are ignored by sbuild. This is done so that package dependencies are predictable; previously, sbuild would consider alternative dependencies, but it made binary package dependencies change based on whether a particular package happened to be installable on unstable at the time of a package rebuild. These changes were unpredictable, and made handling transitions harder than they needed to be. --->8--- Not sure in which section to place this though. Thoughts? -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Bug#950994: Discourage package in contrib to install the real program via another package manager
On Mon, Feb 10, 2020 at 05:48:42AM -0500, Sam Hartman wrote: > I'm not really sure that policy is the best place for this sort of > discouragement though. Why not? Policy discourages loads of things. If we agree that it's not the right thing to do (I'm inclined to agree with that), then we should totally document that in policy. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: RFC: No new Essential packages?
On Sun, Feb 02, 2020 at 01:59:30PM +0100, Bill Allombert wrote: > On Sun, Feb 02, 2020 at 08:08:34AM +0200, Wouter Verhelst wrote: > > On Sun, Feb 02, 2020 at 01:31:14AM +0100, Bill Allombert wrote: > > > On Sat, Feb 01, 2020 at 11:59:34AM -0800, Russ Allbery wrote: > > > > I've never liked the rule that you don't have to declare dependencies on > > > > essential packages and would love to phase it out as much as possible (I > > > > think even intermediate movement in that direction would be useful), but > > > > I'd like Guillem to weigh in from a dpkg perspective to indicate whether > > > > this makes sense to him and whether I'm missing something. > > > > > > This rule is vital to allow for smooth transition when essential > > > programs are moved from one package to another. > > > > It's not? We have programs moving from one package to another all the > > time outside the set of Essential packages, and the sky isn't falling. > > Remember the libc5 to libc6 transition ? Honestly? No. It's been long enough that I hadn't even heard of Debian when it happened, let along that I would be involved (and I have been involved in Debian since 2001). I don't believe this is a coincidence; our processes to do such transitions have improved vastly since those days, and I do not think that we will have another transition as involved as the libc one. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: RFC: No new Essential packages?
On Sun, Feb 02, 2020 at 01:31:14AM +0100, Bill Allombert wrote: > On Sat, Feb 01, 2020 at 11:59:34AM -0800, Russ Allbery wrote: > > I've never liked the rule that you don't have to declare dependencies on > > essential packages and would love to phase it out as much as possible (I > > think even intermediate movement in that direction would be useful), but > > I'd like Guillem to weigh in from a dpkg perspective to indicate whether > > this makes sense to him and whether I'm missing something. > > This rule is vital to allow for smooth transition when essential > programs are moved from one package to another. It's not? We have programs moving from one package to another all the time outside the set of Essential packages, and the sky isn't falling. > This is also necessary to avoid circular-Predepends which are not > supported by dpkg. > e.g. glibc need to predepends on bash because it has a maintainer script > and bash need to depend on glibc. This, however, sure. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: Thinking about Delegating Decisions about Policy
On Fri, Sep 06, 2019 at 11:32:06AM +0200, Bill Allombert wrote: > On Thu, Sep 05, 2019 at 09:17:59AM +0200, Didier 'OdyX' Raboud wrote: > > Le mercredi, 4 septembre 2019, 23.53:06 h CEST Bill Allombert a écrit : > > > On Wed, Sep 04, 2019 at 11:04:57PM +0200, Wouter Verhelst wrote: > > > > > * Most decisions are not just technical decisions, in many/most > > > > > cases > > > > > > > > > > the decisions have answers that are all correct, but it just > > > > > depends > > > > > on the weight of specific trade-offs. How those are weighted > > > > > depends > > > > > heavily on each individual. This also seems rather unfair, as it's > > > > > taking the natural and expected biases of a small set of people in > > > > > the project and forcing them into the entire project. > > > > > > > > Honestly, if the answers are all correct and we've been going around in > > > > circles since like forever, then having a small team decide that one of > > > > these correct answers is now the preferred one and we're going with it > > > > (after listening to all the arguments) hardly seems unfair to me. > > > > > > But then it become a steering committee and not a technical commitee. > > > > Actually, it seems that the Technical Committee has kinda always been doing > > both of these things: arbitration, and steering. > > The way the TC members are selected is not compatible with taking the role > of a steering committee (which need to be properly elected rather than > self-selected). If we're going to change the rules about what the TC does -- or create a whole new committee -- it makes sense to change this part of it, too. So while I agree with you that this is a concern, it doesn't have to be a fatal problem. > (To avoid misunderstanding, I am not in favor of Debian getting a > steering committee. The steering should come from the DPL, who is > elected) I agree that whoever does "steering" needs to be elected. However, I am not convinced that one elected representative is good enough for that; both for long-term stability (DPLs change up to once a year, which is hardly enough for a long-term vision) as well as for allowing multiple viewpoints (the DPL is just one person with his or her own biases; no matter how well the DPL represents the viewpoints of the project at large, it is always better to have multiple people in a position with this kind of power). So I think that Debian could have some limited benefit from a steering group, but I do agree that it needs to be an elected group, not an appointed one. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: Thinking about Delegating Decisions about Policy
On Thu, Sep 05, 2019 at 09:17:59AM +0200, Didier 'OdyX' Raboud wrote: > I have come to wonder if these two functions shouldn't be separated, in > different bodies (eventually with different nomination rules, etc.). This > "steering" question had also been phrased, slightly differently, by Mehdi, > during his DPL term, with the idea of a "Roadmap team". [As I understand it, > a > Roadmap team would pilot the Debian ship with a vision on how to sail the > sees, where the TC, when "steering", decides on a case-by-case in a ship > without captain]. Uncomfortable, for political and availability reasons, the > TC declined to take that role back then. I hadn't looked at it from that angle before, but you're right. In fact, if you look at other distributions, they all have some form of a steering body: Ubuntu has their BDFL, Fedora has the FESCo, OpenSUSE has an elected steering body, and FreeBSD has their core team. I'm sure much of this is true for other distributions as well. Debian does not have a body like this. In some way, this is a feature; we don't have an overarching body that says "X, not Y", and therefore we do both X and Y, and people can just use what they want. Sometimes, however, that doesn't work; when X and Y conflict, we need someone to choose one of the two options. The TC indeed isn't really set up to do this properly, but it gets closest, and therefore it gets to do the job by default. If we are going to make a "steering committee" of sorts, however, or adapt the TC so it can take the role, then I do think we should keep in mind what our historic behaviour has been; that is, that we usually allow multiple options to coexist, and that that isn't necessarily a bad thing as long as they either don't conflict, or a default can be chosen without too much disagreement. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: Thinking about Delegating Decisions about Policy
On Fri, Jul 26, 2019 at 06:45:35PM +0200, Guillem Jover wrote: > * This is a body composed of members that come and go, these might have > wide experience in Debian in general (although not necessarily) or > might had expertise in specific fields. The problem is that this body > gets unbounded topic issues about anything. You cannot expect anyone > w/ no prior experience to have "taste" or "intuition" about things > they have not experienced/practiced for a long time. This is not, > say, a java-ctte composed of Java experts. To be fair, this used to not be the case, but then GR 2014-004 changed that. Although I voted in favour of doing that, in hindsight I'm not sure it was the right decision. [...] > * Most decisions are not just technical decisions, in many/most cases > the decisions have answers that are all correct, but it just depends > on the weight of specific trade-offs. How those are weighted depends > heavily on each individual. This also seems rather unfair, as it's > taking the natural and expected biases of a small set of people in > the project and forcing them into the entire project. Honestly, if the answers are all correct and we've been going around in circles since like forever, then having a small team decide that one of these correct answers is now the preferred one and we're going with it (after listening to all the arguments) hardly seems unfair to me. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Bug#908155: Coordination with upstream developers not universally applied
On Fri, Sep 07, 2018 at 02:14:15PM +0100, Ian Jackson wrote:
> Wouter Verhelst writes ("Bug#908155: Coordination with upstream developers
> not universally applied"):
> > To me, the core message of the current text is that you should ensure
> > that bug reports which are not Debian-specific end up with upstream,
> > *somehow*, whether by the maintainers forwarding it to upstream
> > themselves or by them asking the reporter to do so. Your proposed new
> > text weakens that, and I think that's not a good idea.
>
> How about this
>
>These bug reports should be forwarded to the upstream developers so
>that they can be fixed in a future upstream release. Usually it is
>best if you can do this, but alternatively, you may ask the bug
>submitter to do it.
I think that's better, yes.
It doesn't incorporate my other suggestion about bts-link, though. How about
this:
In cases where a bug report is forwarded upstream, it may be helpful
to remember that the bts-link service can help with synchronizing
states between the upstream bug tracker and the Debian one.
?
--
Could you people please use IRC like normal people?!?
-- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
Hacklab
Bug#908155: Coordination with upstream developers not universally applied
On Thu, Sep 06, 2018 at 09:05:04PM +0200, Moritz Muehlenhoff wrote: > Source: developers-reference > Severity: normal > > "3.1.4. Coordination with upstream developers" says > > "You have to forward these bug reports to the upstream developers so that they > can be fixed in a future upstream release." > > That's not the current/best practice for a number of packages, either because > of the sheer volume of bug reports/size of the package or because some of the > bugs are very specific to the reporters setup and having the Debian maintainer > as a middle person forwarding information back and forth would be useless > (e.g. for the Linux kernel where a lot of bug reports are hardware-specific). > > The current formulation will cause false expections for end users. > > Maybe alternatively make this > > "You can either forward these bug reports to the upstream developers yourself > or ask the reporter to report them upstream, so that they can be fixed in a > future upstream release." I would like something stronger. To me, the core message of the current text is that you should ensure that bug reports which are not Debian-specific end up with upstream, *somehow*, whether by the maintainers forwarding it to upstream themselves or by them asking the reporter to do so. Your proposed new text weakens that, and I think that's not a good idea. I agree that it's perfectly fine for a maintainer to say "this is an upstream bug, please report it upstream", which the current text doesn't allow for. Having said that, I *don't* think it's fine for a maintainer to say "never ever report upstream bugs for this package to Debian"; for someone not familiar with the software in question, determining whether something is a Debian-specific bug or an upstream one is not always possible. While we're at it, I think we should also point out that if upstream uses an issue tracker that is supported by bts-link, it might be nice to keep upstream bug reports that were filed in the Debian bts open, but mark them as forwarded to the correct URL so that bts-link will tag them "fixed-upstream" when relevant. That should probably not be a requirement though. -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab signature.asc Description: PGP signature
Bug#883950: Next steps on "[GPL-3+]" proposal
On Sat, Jul 28, 2018 at 01:51:12PM -0700, Russ Allbery wrote: > One remaining question in my mind is whether we should take the > opportunity of a format change to achieve a few other goals. The most > obvious one would be to reconcile our short license identifiers with SPDX > (probably by making our identifiers a superset of the SPDX ones). The obvious objection to that would be the fact that the SPDX identifiers are not set in stone; a future update of the SPDX identifiers might then conflict with one of the identifiers that we add. Either we'd need a rule to have identifiers namespaced (say, "spdx:mit", and then use "debian:" as a non-spdx namespace, or some such), or a rule to not have non-SPDX identifiers. Personally, I have a preference towards the latter; it seems simpler, and there is benefit to be had to encourage creating a new SPDX identifier over having a "local" fix. -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Bug#891216: seconded 891216: Requre d-devel consultation for epoch bump
On Thu, Jun 28, 2018 at 04:27:12PM +0200, Guillem Jover wrote: > On Thu, 2018-06-28 at 14:34:06 +0200, Wouter Verhelst wrote: > > On Thu, Jun 28, 2018 at 01:43:17PM +0200, Guillem Jover wrote: > > > On Thu, 2018-06-28 at 13:03:56 +0200, Wouter Verhelst wrote: > > > > On Thu, Jun 28, 2018 at 11:39:53AM +0100, Ian Jackson wrote: > > > > > The requirement to consult d-d has worked very well with Pre-Depends. > > > > > Many pointless and harmful Pre-Depends have been avoided this way, > > > > > with very low levels of project-wide effort. > > > > > > > > Yes. There's a difference though. > > > > > > Sure, but not in their harmfulness, though. :) > > > > That's just a matter of opinion. > > I don't think it is though. I'd even say bogus epochs bumps are > potentially more harmful than Pre-Depends! How and in which ways are bogus epochs harmful that uploading a package with the +really convention is not? Downgrading a package is harmful, that's true. In that respect, using a bogus epoch is problematic. However, none of those harmful effects are a result of the use of the epoch; instead, they are a result of the downgrading of a package. Using an epoch in that way is harmful; not because the file now has an extra non-implicit version number (which is just a technical thing), but because you're effectively causing a downgrade on a user's system which breaks dependency relations in unexpected ways. Should we discourage downgrading packages? Yes, absolutely. But that's not what this proposal does. > Pre-Depends are localized in a single package, and their effects can > be easily tested, Not unless you can come up with a solution for the halting problem. > but the validity of the rationale for its introduction might be > difficult or impossible to check automatically, though. But the full > effects of epoch bumps are not easily testable at all and they are > changes with global effect, for all rdepends (in-archive and local), > local forks, etc. I guess your definition of "global effect" differs from mine. At any rate, this isn't really the core of my argument, so meh. [...] > When breaking the release continuity, and forcing an invalidation of > all relationships, it means we might be breaking upgrade scenarios, > satisfiability checks, interface requirement checks, etc, this is a > silent and very harmful thing. Yes, but the issue lies not with epochs; rather, it lies with the fact that you're downgrading the upstream software, which happens regardless of whether you use an epoch or the +really convention. Note: I'm not recommending people use epochs for when the +really convention would suffice. In fact, I'm recommending against downgrading at all, I think we should avoid those if even remotely possible. But adding bureaucracy around epochs because people misuse them for things that they weren't made for and *that are a bad idea to begin with* seems like a pretty bad idea to me. [...] > BTW something I missed in my previous reply, the fact that it might > (should! :) be considered a stigma is IMO a good thing, because it > might make people think at least twice before introducing them. :) Yes, there is that :) [...] > generally missunderstood. I realize that can obviously end up coming > across as very condescending. :/ No worries, been there done that. [...] > > True, but sometimes being bug-compatible can be the right thing to do. > > "can" perhaps, I don't think "right" is the word though. :) Fair enough :) [...] > > I currently maintain two packages which have a non-zero epoch. I think > > that in both cases the decision to bump the epoch was the right one. > > In the two packages you mention, the bump looks entirely legitimate > and for what epochs were intended to be used. For the pmw case I'd > have probably tried to avoid it by talking with upstream so that > they'd have switched to use 4.240 after 4.231 instead of using 4.24. Honestly, I should have called it 4.23.1 rather than 4.231, which is what upstream intended but which he couldn't encode due to implementational details. Ah well. > The other one you have in your DDPO (python-webob), which you were not > involved in, but serves as a nice example, is completely bogus, it was > a release revert, followed by the next upload restoring the continuity. > :( Yeah, like you say, I wasn't involved. I really only did a single sponsored upload of python-webob once, don't even remember the details of it... Anyway, I've said my thing, I think people know about it now. I don't think we should make this a requirement in any form or shape (but would be happy with a strong recommendation if needs be); if I'm alone with that sentiment though, then that probably means the consensus disagrees with me and I'll have to live with it. So, EOT for me. Regards, -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Bug#891216: seconded 891216: Requre d-devel consultation for epoch bump
On Thu, Jun 28, 2018 at 01:43:17PM +0200, Guillem Jover wrote: > On Thu, 2018-06-28 at 13:03:56 +0200, Wouter Verhelst wrote: > > On Thu, Jun 28, 2018 at 11:39:53AM +0100, Ian Jackson wrote: > > > The requirement to consult d-d has worked very well with Pre-Depends. > > > Many pointless and harmful Pre-Depends have been avoided this way, > > > with very low levels of project-wide effort. > > > > Yes. There's a difference though. > > Sure, but not in their harmfulness, though. :) That's just a matter of opinion. > > Incorrect pre-depends are actively harmful. They may cause dependency > > loops which dpkg cannot fix, and may therefore result in problems that > > go way beyond the package which introduced the incorrect pre-depends. In > > that context, I agree that trying to reach consensus on -devel before > > introducing a pre-depends is a good idea. > > > > Incorrect epochs are a nuisance at best. There's a myth going around > > that they cause a "stigma", which I suspect is where this comes from, > > but in actual fact they're just a few extra characters in a version > > number with some special semantics, and nothing beyond that. ^^ > No, they are not just a decorator for the version, they have a > semantic meaning, I know that. > they just reset the sorting order of all previous versions and thus > invalidate any previous relationships. Not any more than do upstream version numbers towards debian revisions. If you consider epoch-zero versions to have "no epoch" (which is wrong), then yes, they imply a "reset". But really, an epoch is just prepending an extra version component before the version number. epochless versions have an implicit zero (okay, I shouldn't be telling you this). Honestly, if this is going to become a requirement, and I didn't want to be bothered with it, I would just use . rather than : as my epoch separator whenever I need to introduce an epoch. The result regarding upgrades etc is *exactly* the same. > For the valid use cases that's an unavoidable transition that one has > to handle, but for the invalid cases it's just unnecessary breakage in > the archive and out-of-archive, in most cases silent breakage! > > Please see > <https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_What_are_version_epochs_and_why_and_when_are_they_needed.3F>. > > > Yes, it's correct that you cannot get rid of an epoch, once it has been > > introduced. This has indeed sometimes caused issues when downstream > > people have introduced epochs in their versions of our packages, causing > > what in effect is an arms race -- but there really is no reason why > > asking on -devel will fix *that* particular issue; I don't think that > > downstreams who fight with us on epochs will do that anyway, so that > > just leaves the debian package maintainer to DTRT and bump the epoch > > there. > > That's really not the right thing to do. That, too, is just a matter of opinion. > That's the equivalent of introducing bogus changes into our packages > to be bug-compatible with external entities. True, but sometimes being bug-compatible can be the right thing to do. > If a downstream unilaterally bumps an epoch, that's their burden to > carry. If our users install epoch-bumped versions of the packages and keep bothering us with "my package don't upgrade no more!!1!", just introducing the epoch in Debian fixes that easily. See debian-multimedia. (yes, that explains the "arms race" bit in my argument, and no, I'm not advocating for doing that *in every case*) [...] > > or some such. But don't make it a requirement -- because it's one I will > > routinely ignore, and I don't think that that should make me run afoul > > of policy. > > If you are "routinely ignoring" this, then your ratio of epoch > introduction would worry me much more than you not asking on d-d. ;) Heh :) I currently maintain two packages which have a non-zero epoch. I think that in both cases the decision to bump the epoch was the right one. No, I won't routinely bump the epoch. But when I need to, I will more often than not ignore such a requirement, is what I meant :) -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Bug#891216: seconded 891216: Requre d-devel consultation for epoch bump
On Thu, Jun 28, 2018 at 12:58:28PM +0100, Ian Jackson wrote:
> Wouter Verhelst writes ("Re: Bug#891216: seconded 891216: Requre d-devel
> consultation for epoch bump"):
> > Incorrect epochs are a nuisance at best.
>
> The problem is that they are a permanent nuisance. This discussion
> was prompted when someone caused significant trouble by *only* bumping
> the epoch.
Can you point me towards the specifics?
Also, would a requirement in policy have prevented this, or was it just
a case of "the maintainer was a bit sloppy"? In that case, I believe
they would probably have missed this requirement, too, and then we're
just adding more bureaucracy for the sake of it.
[...]
> > Yes, it's correct that epochs cause confusion, because some bits of our
> > infrastructure drop the epoch in the filename. I submit that that is in
> > fact a bug in that bit of infrastructure; epochs are a critical part of
> > the version number, and they should not be dropped, ever.
>
> There are very good reasons why epochs are dropped in filenames. I'm
> afraid I stand by that decision.
I will readily believe that there are good reasons for dropping colons
in filenames. I'm not so sure about the epoch itself though; I'm sure it
must be possible to encode an epoch in a filename while avoiding a
colon.
Having said that, I must admit I don't know the full background on this,
and it isn't really the core of my argument, so I'll just take your word
for it.
[...]
> > But if we're going to introduce the *requirement* to ask on -devel for
> > every nitty bitty thing
>
> I can see where you are coming from with this. Can I persuade you
> that this is worthwhile in this case because enough other people care
> about it, even if you personally think it's not that big an issue ?
If I'm the only one bothered enough to speak up against this, I suppose
that'd be the outcome, yes (or it might be that other people who think
this is silly just don't care enough)
> > "Please note that introducing an epoch is an irreversible action. If
> > you're uncertain of whether the introduction of the epoch is the right
> > thing to do, it is best to ask on the debian-devel mailinglist."
>
> One of the problems with your formulation is that people who do not
> know what they are doing, do not know that they do not know what they
> are doing.
Fair enough, I suppose.
> See Dunning & Kruger's paper.
>
> (I know that "Dunning Kruger" is used as an insult, but that is ... at
> best a very loose usage. Because not knowing that you are wrong is a
> feature of being wrong, and doesn't imply stupidity.)
Honestly, hadn't even heard of that before today :-)
> How about a "should" ? I think that most people won't ignore a
> "should" unless they feel they understand why it's there.
Yeah, that works well as a compromise.
--
Could you people please use IRC like normal people?!?
-- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
Hacklab
Bug#891216: seconded 891216: Requre d-devel consultation for epoch bump
On Thu, Jun 28, 2018 at 11:39:53AM +0100, Ian Jackson wrote:
> Wouter Verhelst writes ("Bug#891216: seconded 891216: Requre d-devel
> consultation for epoch bump"):
> > I would oppose this change.
>
> > Documenting why you should not use epochs in certain cases does make
> > sense, but I think we should trust our developers to understand what
> > they're being told, rather than requiring people uselessly email -devel
> > (and clutter that mailinglist, which also causes harm).
>
> My perception of our experience is that trying to get people to make
> the right choice solely by writing things in documents is not
> effective.
>
> Epochs are frequently misunderstood and used where it would have been
> better not to use them. Proper usage of an epoch is sufficiently rare
> that asking for a review is reasonable. We do not have a central code
> review board or anything; debian-devel is the closes thing we have.
True.
> The requirement to consult d-d has worked very well with Pre-Depends.
> Many pointless and harmful Pre-Depends have been avoided this way,
> with very low levels of project-wide effort.
Yes. There's a difference though.
Incorrect pre-depends are actively harmful. They may cause dependency
loops which dpkg cannot fix, and may therefore result in problems that
go way beyond the package which introduced the incorrect pre-depends. In
that context, I agree that trying to reach consensus on -devel before
introducing a pre-depends is a good idea.
Incorrect epochs are a nuisance at best. There's a myth going around
that they cause a "stigma", which I suspect is where this comes from,
but in actual fact they're just a few extra characters in a version
number with some special semantics, and nothing beyond that.
Yes, it's correct that you cannot get rid of an epoch, once it has been
introduced. This has indeed sometimes caused issues when downstream
people have introduced epochs in their versions of our packages, causing
what in effect is an arms race -- but there really is no reason why
asking on -devel will fix *that* particular issue; I don't think that
downstreams who fight with us on epochs will do that anyway, so that
just leaves the debian package maintainer to DTRT and bump the epoch
there.
Yes, it's correct that epochs cause confusion, because some bits of our
infrastructure drop the epoch in the filename. I submit that that is in
fact a bug in that bit of infrastructure; epochs are a critical part of
the version number, and they should not be dropped, ever.
But if we're going to introduce the *requirement* to ask on -devel for
every nitty bitty thing that might possibly somewhere down the road
cause some confusion in some inexperienced developer, then in the end
the -devel mailinglist will devolve to a list where senior DDs come by
to ask "can I please introduce a postinst to my package?" and that's
just a waste of everyone's time.
That (and a feeling that I'll just balk at wasting my time by asking on
-devel "please pretty please can I introduce an epoch please") is why
I'm oposed to introducing this requirement.
> > But requiring a consensus on -devel seems like wasting people's time to
> > me.
>
> I don't care whether it's consensus or consultation. In practice
> there are not going to be big arguments about this.
Which is another reason why we shouldn't introduce the requirement.
I'd be okay with a recommendation along the lines of
"Please note that introducing an epoch is an irreversible action. If
you're uncertain of whether the introduction of the epoch is the right
thing to do, it is best to ask on the debian-devel mailinglist."
or some such. But don't make it a requirement -- because it's one I will
routinely ignore, and I don't think that that should make me run afoul
of policy.
--
Could you people please use IRC like normal people?!?
-- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
Hacklab
Bug#891216: seconded 891216: Requre d-devel consultation for epoch bump
I would oppose this change. On Wed, Jun 13, 2018 at 11:13:27PM +0200, Paul Gevers wrote: > I second the diff below. > > Paul > > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst > index 0771346..166cdd8 100644 > --- a/policy/ch-controlfields.rst > +++ b/policy/ch-controlfields.rst > @@ -552,9 +552,10 @@ The three components here are: > omitted, in which case zero is assumed. If it is omitted then the > ``upstream_version`` may not contain any colons. > > -It is provided to allow mistakes in the version numbers of older > -versions of a package, and also a package's previous version > -numbering schemes, to be left behind. > +Epochs can help when the upstream version numbering scheme > +changes, but they must be used with care. You should not change > +the epoch, even in experimental, without getting consensus on > +debian-devel first. There is no harm in an epoch. It's a part of the version number. Yes, it is a part that cannot be lost, but it does not cause any harm to the distribution if they are used incorrectly. The same is not true for preinst scripts; when those are overused, packages may end up not being installable anymore, which does actively cause harm. Documenting why you should not use epochs in certain cases does make sense, but I think we should trust our developers to understand what they're being told, rather than requiring people uselessly email -devel (and clutter that mailinglist, which also causes harm). > ``upstream_version`` > This is the main part of the version number. It is usually the > @@ -622,9 +623,23 @@ These two steps (comparing and removing initial > non-digit strings and > initial digit strings) are repeated until a difference is found or both > strings are exhausted. > > -Note that the purpose of epochs is to allow us to leave behind mistakes > -in version numbering, and to cope with situations where the version > -numbering scheme changes. It is *not* intended to cope with version > +Epochs should be used sparingly > +^^^ > + > +Note that the purpose of epochs is to cope with situations where the > +upstream version numbering scheme changes and to allow us to leave > +behind serious mistakes. This makes sense. > +If you think that increasing the epoch is the right solution, > +you should consult debian-devel and get consensus before doing so > +(even in experimental). This, I think, should be removed. > +Epochs should not be used when a package needs to be rolled back. > +In that case, use the ``+really`` convention: for example, if you > +uploaded ``2.3-3`` and now you need to go backwards to upstream 2.2, > +call your reverting upload something like ``2.3+really2.2-1``. > +Eventually, when we upload upstream 2.4, the +really part can go away. > + > +Epochs are also not intended to cope with version > numbers containing strings of letters which the package management > system cannot interpret (such as ``ALPHA`` or ``pre-``), or with silly > orderings. [#]_ These make sense, too. We could add another paragraph saying what the downsides of epochs are, and why they should be avoided. But requiring a consensus on -devel seems like wasting people's time to me. -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
On Sat, Jul 01, 2017 at 08:52:29AM -0700, Russ Allbery wrote: [...maintaining non-Debian-specific software as a native package...] > I certainly think it's not good practice. I think it depends on the particulars of the situation. I am upstream for two of the packages I maintain for Debian: nbd and fdpowermon. For nbd, I maintain it as an upstream package on sourceforge and github, and as a non-native Debian package. For fdpowermon, I just maintain it as a native package. I do this, simply, because the package is fairly trivial -- the most important bit is a (currently) 573-line perl script (and that's including POD documentation). While it's certainly possible to ship an "upstream" Makefile.PL or some such with this package, that feels like overkill and generally not worth it. Additionally, the packaging is so simple that updating the package for just the packaging is rare, if it even happens at all, so just about every update I've ever done was relevant for people who did not use Debian, too. While I agree that Debian is not a general software distribution platform, and that therefore shipping software like this isn't necessarily a good idea, for me as a Debian developer it is significantly easier to just maintain it this way and not have to worry about the extra overhead (even if it's a pretty small overhead) that an "upstream" release would involve. [...] > Bumping the minor version for things that no one cares about (because they > only affect people consuming it from Debian) is probably between you and > your users, although I think it's poor practice and would be vaguely > irritated by it. I can see why that might be the case, but given that in the case that I quote above that is actually quite rare, I'm not sure it's a problem. > But the stronger argument against this approach is NMUs and change of > maintainership. As soon as such a package is NMU'd for whatever > reason, or if you no longer have time to maintain the package for > Debian but are still developing it upstream, the native package status > gets really awkward. I'm not sure this is true. By uploading a native package into Debian, I take the "risk" that at some point someone will have to do an NMU, yes. Indeed, if I instead hosted the package on some upstream hosting site, then nobody but me will be able to do releases of fdpowermon. But that's not a major issue; I trust that my fellow developers won't abuse that right (indeed, they don't usually do so). If I ever find myself in the situation where I stop maintaining fdpowermon in Debian but continue maintaining it upstream, then converting the package from a native to a non-native one is fairly trivial. In fact, I've occasionally uploaded nbd as a native package by accident, because dak doesn't actually care, and neither do our build tools (when using source format 1.0). As such, if that situation ever happens, then moving to a non-native package is trivial, and there is no awkwardness. [...] > I've also repeatedly had the experience as upstream maintainer that I > actually do need to carry a Debian-specific patch for a while, since > Debian needs some quick fix that I don't want to take upstream in the same > form. Indeed; for nbd, I've occasionally had to do that as well. Usually it's a cherry-pick from upstream master or some such, where a bug was first exposed in one of our more obscure ports; and while I do want to release it upstream, just doing a new upstream release just so I can release a bugfix for alpha or hurd or whatnot isn't really worth it. For a simple perl script which by its very nature has little portability issues and therefore small chances for requiring such patches, I don't think it's worth fussing about though. A somewhat more complicated example is ikiwiki; when Joey was still maintaining it for Debian (before he resigned from the project), it was also a native package. At the time, the package version number was just the git checkout date, as in, "we don't really do upstream releases, what's in Debian is just a snapshot from the git repository". That, too, seems like a reasonable approach to me. I guess what I'm saying is that it really depends on the particulars of how you maintain the software; and that while in general it's probably a bad idea, there can be corner cases where it isn't necessarily a bad idea, can even be a good idea, and certainly takes away some overhead and extra work that wouldn't be necessary at all if not for the fact that you're doing a non-native version and therefore need to do an "upstream" release before you can do a Debian release. Regards, -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Re: FYI: Update to GPL notices
On Wed, May 31, 2017 at 10:02:53AM -0700, Russ Allbery wrote: > Wouter Verhelst <wou...@debian.org> writes: > > On Mon, May 29, 2017 at 05:35:47PM -0700, Russ Allbery wrote: > > >> As part of the XML conversion, I noticed the GPL notices on the three > >> documents released under the GPL were the older form that had an FSF > >> street address. I updated them to the current recommended form, > >> including switching to all-caps for the warranty disclaimer in the > >> recommended way (sometimes weird things matter for legal notices, so > >> may as well not get creative). > > > Yes, indeed they do. > > > I was under the impression, though, that the address form is the > > preferred form for version 2 of the license, whereas the website form is > > the preferred one for version 3 of it. > > > I might be wrong, though. > > The address form is the recommended form in the text of the GPLv2, but I'm > 95% sure that's only because the FSF haven't changed anything at all about > the GPLv2 since the GPLv3 was released. Since the address information is > effectively contact information for the FSF, I wouldn't think it would be > license-specific; if they (and, more importantly, their lawyers) are now > comfortable with a URL, I think it makes sense to just go ahead and follow > the GPLv3 license notice form. Sure. My thinking always went something like, the GPLv3 has language that allows a person redistributing the covered work to point to the source on a network server (if they haven't made modifications), rather than to have to offer it to anyone. In that light, it might make a difference according to the license itself. IANAL though, and I haven't actually ever read the GPLv3 in much detail. I could be wrong. > Keeping the address also runs the risk of the address becoming out of > date, which has already happened once in the past. So this is a bit more > future-proof. There's that too, yes. -- Help me, off-by-one kenobi. You're my only nought.
Re: FYI: Update to GPL notices
On Mon, May 29, 2017 at 05:35:47PM -0700, Russ Allbery wrote: > As part of the XML conversion, I noticed the GPL notices on the three > documents released under the GPL were the older form that had an FSF > street address. I updated them to the current recommended form, including > switching to all-caps for the warranty disclaimer in the recommended way > (sometimes weird things matter for legal notices, so may as well not get > creative). Yes, indeed they do. I was under the impression, though, that the address form is the preferred form for version 2 of the license, whereas the website form is the preferred one for version 3 of it. I might be wrong, though. -- Help me, off-by-one kenobi. You're my only nought.
Bug#844431: policy: packages should be reproducible
On Sun, May 14, 2017 at 11:15:26PM +, Holger Levsen wrote: > On Mon, May 15, 2017 at 12:05:17AM +0200, Bill Allombert wrote: > > On Sun, May 14, 2017 at 03:20:54PM +, Holger Levsen wrote: > > > On Sun, May 14, 2017 at 05:05:36PM +0200, Bill Allombert wrote: > > > a.) go to http://reproducible.debian.net/$srcpkg and see if its > > > reproducible today. > > As I said, I would like to check that my package build is reproducible > > before > > I upload it, not after, so I can be sure that any bug is fixed in the > > upload. > > b.), b.0), c.) and d.) were given as possible "tools" *to build twice with > (some) variation(s) and compare the results*. > > "Reproducible Builds" (in the sense of bit by bit identicall builds) is > really a rather new field in the era of software (well, not really, but > thats history and bit rotted until it was rediscovered in the early 2010s…) > > What is trivial, if given, is to show that a package is *un*reproducible. > > It's much harder to show that a package is reproducible. > > And given that this is a new field I think it's ok, while somewhat > unsatisfying, > that maybe some unreproducibility will only be detected by a more advanced > tool, like reproducible.debian.net (which aint a,b,c nor d, but e.) > after an upload has taken place. I think it's probably not a good idea to (when we've moved to mandate "packages must be reproducible") allow packages to become insta-buggy by things that are out of their control and not clearly specified in policy. That's not how we do things in Debian. As such, I would favour the following approach: - You guys (= the reproducible builds guys) come up with a list of things that commonly make a package nonreproducible today, and policy adds those as "should not"s. If I'm not mistaken, such a list already exists, you may simply need to generalize it a bit? - Actually, I'm sure there may be things that packages failed to comply with in the past, but that are not a problem anymore today; we can make those "must not" rules already today. - If you find new and interesting ways to make packages nonreproducible at some point in the future, those can be added (as "should" first, and as "must" later). This would result in a section in policy of this form: --- # Reproducible builds Packages should generally be reproducible. That is, a package build should result in a bit-by-bit identical package from one build to the next. Specifically, packages must not do any of the following things: - non-reproducible thing A - non-reproducible thing B - ... Moreover, while the following are not must rules yet, packages should also not do any of the following things: - still-in-the-wild non-reproducible thing A - still-in-the-wild non-reproducible thing B - ... --- (wording may need some tweaking) The above wording makes "bit-by-bit identical" a should (so packagers are encouraged to reach that goal), but already allows you to file RC bugs on some subset of "is not reproducible" package issues, and a subset that will improve over time. With that wording, I don't think we should ever make "bit-by-bit identical" a must; I also don't think we would need to. As you say, building packages nonreproducibly is difficult to define, and it certainly is difficult to test for in a definite manner. > > What parameters > > are allowed to change need to be defined. > > I sadly think this is impossible. I agree that it will probably be a neverending effort, but I also think it's the only way that it can reasonably be done. -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12
Re: Use questions
Hi Mark, On Wed, Apr 05, 2017 at 11:06:32AM -0400, Mark Gabrielli wrote: > We are using your software with a lighting controller. Is there anything we > need to do to legally include this once we retail the unit? The licenses of the software which we ship can be found in /usr/share/doc//copyright. In general, the answer is no; however, for GPL-licensed software, you must do one of the following: - Ship the source code of the GPL-licensed software with your product - Ship an offer to provide the source code of the GPL-licensed software at "reasonable cost" to whoever asks for it. There are a number of packages in Debian which are GPL-licensed and which have this requirement. If you make no modifications to Debian itself, then the easiest way to comply with this requirement is to download our "source" CD or DVD images, and send them to whomever asks for it (you should do so when you create the "master" image for your device, so that the source which you ship matches the binaries that you shipped). If you do make modifications, you should check the licenses of the packages that you are changing for the requirements in the license; they may require more than just the ability to ship sources. -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12
Re: Servers going online automatically?
On Tue, Dec 08, 2015 at 08:44:22PM +, Vesa Paatero wrote: > Thanks for the link. Even as you admit in the article that "it is a frequent > beef against Debian that on Debian, network services get started immediately > after the package was installed", maybe we should keep our antennas up for > any useful ideas to make that default/policy more visible to those whom it > otherwise would take by surprise. It is also part of that policy that while they're enabled by default, their default configuration should not be secure. That is, serving content read-only is allowed, but not read-write by default, and the served content should not leak information either. As an example of the latter, we ship cups with the browsing protocol disabled by default; also, relevant policies have been changed in the past when it was discovered that there are some packages which allow to redirect localhost-only HTTP, so that even through such packages, the list of packages installed could not be discovered by going to the "/doc" alias. If you know of more such issues, feel free to suggest more such improvements. However, I think the policy of enabling network services by default is a sensible one, and we should not lose it. > .. . . Admitted, it is generally a challenging problem to have the > right piece of documentation show up at the right time and place for > the audience that would benefit from it. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
Bug#707851: Debian Menu Systems : Implementation of the TC decision
On Tue, Oct 13, 2015 at 07:56:03AM -0400, Sam Hartman wrote: > >>>>> "Wouter" == Wouter Verhelst <wou...@debian.org> writes: > > > Wouter> So, I'm with Guillem on this one. > > > Wouter> But _forbidding_ maintainers who want to from shipping a > Wouter> second file, if that somehow makes the experience of menu > Wouter> users better than what the fdo menu would have given them? > Wouter> Sorry, but that seems petty and silly. > > OK. > Then why don't you build consensus behind a patch to do that? > The TC's decision can be changed by the normal policy process. > If you can get people to agree with a proposal that permits both > ..desktop and .menu files then you can replace the TC decision. Per §4.1.4, Only through a 2:1 supermajority GR. Alternatively, it could also by replaced by the TC voting a second time on the subject, changing or clarifying its original decision (an outcome I would favour, but hey, I'm not a member of the TC). > For myself, I think that forcing a transition to .desktop will create a > longer Debian long-term. [assuming you meant 'better' rather than 'longer'] Yes, I agree with that, and I support that goal. By stating that the absense of a .desktop file for a graphical program should be considered a bug, and that the absense of support for the fdo menu in a window manager should be considered a bug as well, you would have forced such a transition, and that would/should have been enough. In contrast, the current TC decision goes one step further, and I think it goes a bridge too far. > I believe that the TC's approach provides a useful push for that in > this situation. I realize that it is a fairly forceful approach and > it's not something that Debian does often. Exactly, and that is one of the major reasons why I think it's a bad decision. (for reference: I'm not angry here, just critical and sceptical) Regards, Wouter -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
Bug#707851: Debian Menu Systems : Implementation of the TC decision
On Tue, Sep 29, 2015 at 11:39:47AM +0200, Didier 'OdyX' Raboud wrote: > Le mardi, 29 septembre 2015, 02.10:01 Guillem Jover a écrit : > > Wow, this is such terrible policy… So we have supporters of the XDG > > format, and supporters of the menu format. Some of those would and > > have accepted files of their non-preferred format in their packages, > > some have outright refused them. But now they have to choose between > > one of them, because they can no longer ship both. > > One of the points of the TC decision is precisely to avoid a "free > choice" between the two formats. The first point of that decision is to > adopt ba679bff76f5b9152f43d5bc901b9b3aad257479 in the Debian Policy, > which contains: > > Packages shipping applications that comply with minimal requirements > > described below for integration with desktop environments should > > register these applications in the desktop menu, (…) > > Applications "should" be registered in the FreeDesktop menu if that > makes sense. The second point of the TC decision (which phrasing to be > committed in the Debian Policy we're currently discussing) is to forbid > applications that do provide XDG menu entries to _also_ provide "trad > menu" entries. So, I'm with Guillem on this one. Saying that the FreeDesktop menu should be the default and "source" format, I wholeheartedly support that choice. Making it clear that not shipping a .menu file is not a bug, and that it is a bug (not necessarily RC, but still) for a window manager to not look at the fdo menu? Sure, great policy. But _forbidding_ maintainers who want to from shipping a second file, if that somehow makes the experience of menu users better than what the fdo menu would have given them? Sorry, but that seems petty and silly. I don't think I'll encounter the issue, seen as none of my packages ship any menu entry, let alone a .desktop file, today. But yeah, it's something I think I'll blatantly ignore if/when the time comes. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
Re: Bug#741573: #741573: Menu Policy and Consensus
Hi Sam, [side note: while I joined the original discussion, I don't really have a stake in the outcome, other than the desire to have a working menu] On Tue, Jul 21, 2015 at 09:06:08AM +, Sam Hartman wrote: Should Bill have recused? Your current process does not describe when policy editors should recuse. One thing we may learn here is that we need to be more clear about how we handle recusals. I'm not sure if the lack of a policy on recusals is a good excuse for the failure to do so. If Bill opposed the proposal (which certainly is his right), he *should* have actively partaken in the discussion, pointing out *why* he thought it a bad idea and asking for clarifications, improvements, etc. Instead, he mostly ignored the discussion while it was happening (not counting the occasional mails pointing out what he believed to be inaccuracies), and only making fully clear that he was going to oppose the proposal when he reverted the commit that implemented what others thought to be consensus. I don't think this is appropriate for anyone, regardless of whether they're policy editors. If you have an objection to a technical change in Debian, historically we've always required that people come up with technical reasons for either supporting or objecting to, the change. Bill did not do that, at least not to the level I would expect from someone who opposes a proposed change that seems to be building consensus. Anyway. While I applaud your attempts to get the original people around the table again, I'm not sure that's either productive or the role of the TC. Not productive, because I feel that the different parties have pretty much reached set positions that they're extremely unlikely to deviate from anymore; and not the role of the TC, because it is the technical committee's role to take *technical* decisions, which this approach would not necessarily lead to. Instead, I would prefer if the technical committee would, after reviewing the arguments pro and con, take a decision on *which menu system* to move forward with, rather than trying to fix the original discussion, for which I have little hope that it will be successful. I do believe Charles' original mail was a request for the TC to do so. If it isn't in your interpretation, please consider this an official request in that manner. Thanks, -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 signature.asc Description: Digital signature
Bug#676784: Policy §10.5 and .jar file noticeable exception
On 03-08-13 08:40, Charles Plessy wrote: tag 676784 pending thanks Le Tue, Jul 30, 2013 at 10:13:37PM +0900, Charles Plessy a écrit : Unless there is objection, I will add the note in parenthesis as a non-normative change, and then mark the bug pending. Hello everybody, here is what I pushed. diff --git a/debian/changelog b/debian/changelog index fe4a858..bc23f5c 100644 --- a/debian/changelog +++ b/debian/changelog @@ -51,6 +51,7 @@ debian-policy (3.9.5.0) UNRELEASED; urgency=low Closes: #704657. Thanks, Philipp Hahn. * Replaced non-standard names of dpkg states by normalised ones. Closes: #705403 + * Clarify what is meant by compressed in section 10.5. (Closes: #676784) -- Russ Allbery r...@debian.org Sat, 03 Nov 2012 15:32:46 -0700 diff --git a/policy.sgml b/policy.sgml index 953d5d2..cb1093f 100644 --- a/policy.sgml +++ b/policy.sgml @@ -8853,7 +8853,9 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq /p p - A symbolic link pointing to a compressed file should always + A symbolic link pointing to a compressed file (in the sense + that it is meant to be uncompressed with prgnunzip/prgn This should be gunzip, not just unzip. The latter unpacks the .zip format, not the .gz one, which is significantly different. + or prgnzless/prgn etc.) should always have the same file extension as the referenced file. (For example, if a file filefoo.gz/file is referenced by a symbolic link, the filename of the link has to end with Cheers, -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- 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/51fdfd3e.7010...@debian.org
Re: Bug#707851: debian-policy: soften the wording recommending menu files
On 14-05-13 23:28, Bill Allombert wrote: On Sun, May 12, 2013 at 12:51:13PM +0200, Sune Vuorela wrote: For fluxbox, openbox, blackbox, fvwm, icewm, windowmaker, gnustep and probably others, there exists scripts that convert a XDG menu structure into their own formats, not unlike currently where scripts is used to convert the debian menu structure into their own formats. None of those scripts are compliant with the XDG menu specification. Do we need full compliancy, or do we need a useful menu? I'm inclined to believe the latter is the case, and that it is possible to get the latter without the former. By constrast, Debian menu supports at least 36 window managers. But the Debian menu is not used by the most popular user interfaces in Debian (GNOME, and soon also KDE), reducing its effectiveness in providing a common menu structure for our users. I do not see any benefit to dismantle Debian menu at this stage. I do not see any benefit in steadfastedly holding on to it when its usefulness is being further and further reduced and its functionality superseded upstream. Bill, I understand your desire to defend your turf. But I think it's time to realize that the Debian menu has outlived its usefulness. There was a time when nothing similar to the Debian menu system existed, and the common menu system was one of Debian's major features; but that time is long past now, and a common menu system has been implemented upstream. We shouldn't try to hang on to what effectively has become superseded technology just for the sake of it. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- 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/5194bc17.2040...@debian.org
Bug#707851: debian-policy: soften the wording recommending menu files
On 15-05-13 08:23, Raphael Hertzog wrote: (Your last mail was not sent to the BTS but to the ML directly) On Tue, 14 May 2013, Wouter Verhelst wrote: I didn't mean to imply someone other than the relevant UI maintainers would need to write code for this to happen; we could simply add some wording along the lines of packages that install desktop files must emit the ``desktop-files-installed'' trigger from their postinst (e.g., by running ``dpkg-trigger desktop-files-installed''), so that user interfaces which don't support desktop files directly can listen to this trigger and update their menus. A file trigger on /usr/share/applications does exactly that. There's no need to formalize anything more IMO. Ah, yes, hadn't thought of that. How about this then: Packages providing a menu system should preferably support the desktop format (see section xref). When such support is absent, as an alternative the package should preferably register a file trigger on /usr/share/applications and use the desktop files there as a basis to be converted to their native menu format. Should, so as to not make such packages insta-buggy, but still strong enough that it is clearly something these packages should look into. I think we should encourage shared menu systems; whether they are menu files are desktop files does not matter as much. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- 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/51935d5a.3040...@debian.org
Bug#707851: debian-policy: soften the wording recommending menu files
On 14-05-13 23:31, Bill Allombert wrote: On Tue, May 14, 2013 at 12:50:14PM -0700, Russ Allbery wrote: Wouter Verhelst wou...@debian.org writes: On 13-05-13 10:02, Josselin Mouette wrote: Packages can, to be compatible with Debian additions to some legacy window managers, also provide a menu file. Such menu entries should follow the Debian menu policy, which can be found in the menu-policy files in the debian-policy package. It is also available from the Debian web mirrors at /doc/packaging-manuals/menu-policy/. If we're going to suggest desktop files in policy, I would rather prefer that we change window managers to read desktop files instead of menu files, and remove this suggestion altogether. Having two ways to specify menu entries means you'll get two half menus rather than one whole, which isn't a good idea. So would everyone else, but no one has done the work. I think enough years have gone by that it doesn't make sense to keep waiting for someone to volunteer to do this work for the less common window managers like fvwm. Because this is not possible. The XDG menu specification requires funky stuff like XSLT processing which are not compatible with the spirit of a lightweight window manager. Do you have any reference to that? Also, I don't think the requirement should be anything like you must implement the desktop format to the letter; more like you should distill a usable menu from things in /usr/share/applications. Sometimes this may mean losing information, but that's probably fine. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- 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/51935dd7.6060...@debian.org
Re: Bug#707851: debian-policy: soften the wording recommending menu files
Hi, On 12-05-13 02:04, Michael Biebl wrote: Hi Russ, hi Sune, I'd like to second this request to reword the current section in the policy regarding menu files, suggesting fdo .desktop files as the recommended mechanism and make it clear that .menu files are only really relevant for legacy or more exotic window managers. I am not opposed, in principle, to switching to desktop files and away from .menu file -- at least not anymore. But if we're going to do that, we should do it right. Sune's patch looks fine to me. It refers to some (unspecified) window manager implementations as legacy, which I think is a no-go (if they're supported in Debian, by definition they're not legacy). Apart from that, I would like to see rough feature parity, i.e., - support for applications which start from a terminal, using the x-terminal-emulator alternative), without hardcoding the terminal emulator (for pdmenu or similar things) (possibly desktop files already support this; if so, feel free to just point that out ;) - per-user desktop entries (~/.menu, and update-menus run as user) that are not specific to the used user interface. (same note as on the previous item) - an easy way for window managers that don't use the desktop format directly to be told when there are new entries and they need to rebuild their menu. With the Debian menu system, we have update-menus which is called at postinst time (possibly by a trigger, I'm not sure); there should be something similar for desktop entries. This might simply be implemented by a dpkg trigger that all interested window managers listen to and that desktop-installing packages should emit; but we should document such a procedure before making this switch. Moreover, we should have clear policies on what the contents of a .desktop file should look like, that goes way beyond just a vage URL over at freedesktop.org. Specifically, we need: - a replacement for our current menu policy which explains which types of applications will go where. Consistency across user interfaces is a *good* thing, and to get that we'll need to make some decisions ourselves, sometimes overriding upstreams. That should obviously be the exception rather than the rule (i.e., we should construct something that would allow us to keep most upstream desktop files, for whatever definition of most makes sense). Consistency across choice is one of Debian's strengths; we should strive to keep that feature. - A decision/clarification on what will happen when a desktop file contains the only show this in GNOME feature (with which they *actually* mean don't show this in KDE) and the user interface in use is neither of those two. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ signature.asc Description: OpenPGP digital signature
Bug#707851: debian-policy: soften the wording recommending menu files
On 13-05-13 10:02, Josselin Mouette wrote: * The maintainer should use the “debian-desktop” mailing list too coordinate with maintainers of menu implementations, in order to avoid bad interactions with other icons or wrong categories. Especially for packages which are part of installation tasks, the contents of the NotShowIn/OnlyShowIn stanzas should be validated by the maintainers of the relevant environments. I would prefer that we have an enumeration of possible categories, in policy, with an explanation of which kind of applications should go where. That enumeration can then still end with in case of doubt, contact the debian-desktop mailinglist. Packages can, to be compatible with Debian additions to some legacy window managers, also provide a menu file. Such menu entries should follow the Debian menu policy, which can be found in the menu-policy files in the debian-policy package. It is also available from the Debian web mirrors at /doc/packaging-manuals/menu-policy/. If we're going to suggest desktop files in policy, I would rather prefer that we change window managers to read desktop files instead of menu files, and remove this suggestion altogether. Having two ways to specify menu entries means you'll get two half menus rather than one whole, which isn't a good idea. [...] -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- 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/51928673.3070...@debian.org
Re: Bug#707851: debian-policy: soften the wording recommending menu files
Hi Russ, For clarity: I never meant to say we should hold off on discouraging desktop files unless and until all that is available; just that we should consider all those things too, and that (at some point) we need to ensure we have them. Since we're discussing changing to desktop files now, however, this seems as good a time as any to at least think about the issues. If some of them can be implemented by adding the correct wording to policy, then why not? On 14-05-13 20:42, Russ Allbery wrote: Wouter Verhelst wou...@debian.org writes: It refers to some (unspecified) window manager implementations as legacy, which I think is a no-go (if they're supported in Debian, by definition they're not legacy). I think it's fair to say that not supporting desktop files for the menu infrastructure makes a window manager legacy at this point. I use one of those window managers personally, but the fact remains that this is the direction in which the whole desktop world has gone, and most new window managers, even those that aren't really trying to provide a desktop environment, support them to the degree that they do things related to desktop files. The point that I was trying to make (but failed, I agree) is that we shouldn't have to support legacy in Debian. If we decide to switch, we should switch, and drop the old -- not talk about legacy. That just doesn't make any sense to me. If a window manager in Debian is still supported, it won't be legacy, and (if we switch to desktop files) it will support desktop files; either through reading them directly, or through having maintainer scripts convert them into something the window manager understands. Apart from that, I would like to see rough feature parity, i.e., - support for applications which start from a terminal, using the x-terminal-emulator alternative), without hardcoding the terminal emulator (for pdmenu or similar things) (possibly desktop files already support this; if so, feel free to just point that out ;) I'm fairly sure they do. This is the Terminal=true setting. Good, ignore that bit then :-) - per-user desktop entries (~/.menu, and update-menus run as user) that are not specific to the used user interface. (same note as on the previous item) Already supported, although where you have to put the desktop file varies depending on the environment. There is slow convergence (I think) on the XDG paths, but we're not there yet. Well, if upstream is working on something, I suppose we don't need to work on it ourselves anymore :-) - an easy way for window managers that don't use the desktop format directly to be told when there are new entries and they need to rebuild their menu. With the Debian menu system, we have update-menus which is called at postinst time (possibly by a trigger, I'm not sure); there should be something similar for desktop entries. This might simply be implemented by a dpkg trigger that all interested window managers listen to and that desktop-installing packages should emit; but we should document such a procedure before making this switch. It would be ideal if we had something like this in place, but the reality of the situation is that we're already making this switch, and no one is stepping forward to do this work. At some point, I think it becomes the obligation of the fvwm (etc.) maintainers to do this work if they want to see it done, rather than asking the GNOME and KDE and Xfce maintainers to write code for window managers they don't use and don't support in order to move forward with their upstream direction. I didn't mean to imply someone other than the relevant UI maintainers would need to write code for this to happen; we could simply add some wording along the lines of packages that install desktop files must emit the ``desktop-files-installed'' trigger from their postinst (e.g., by running ``dpkg-trigger desktop-files-installed''), so that user interfaces which don't support desktop files directly can listen to this trigger and update their menus. That still leaves the actual implementation up to the maintainers of the relevant window managers, but clarifies how it would be implemented technically. [...] Moreover, we should have clear policies on what the contents of a .desktop file should look like, that goes way beyond just a vage URL over at freedesktop.org. Specifically, we need: The URL is really not that vague, speaking as someone who wrote the Lintian validation code based on the specification. It is vague in that it's just a URL to an external specification for something that we'll be using quite extensively. I haven't read the actual specification, but I think the two things I pointed out are things that should be specified in policy rather than be specified as do whatever it is that upstream does, we don't care. - a replacement for our current menu policy which explains which types of applications
Re: Bug#582109: debian-policy: document triggers where appropriate
On 10-04-13 12:07, Raphael Hertzog wrote: “prgndpkg/prgn triggers allows packages to monitor events caused by It should be allow here, not allows, since the subject (triggers) of this sentence is in plural form. [...] + whitespace, everything after the first hash character (tt#/tt) whitespaces ? (with s) No, absolutely not. The word whitespace does not have a plural form, since it is not a noun (you cannot say a whitespace, for instance). -- 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/51653dc2.4000...@debian.org
Re: Bug#582109: debian-policy: document triggers where appropriate
On 10-04-13 12:37, Simon McVittie wrote: hat class=native-en_GB-speaker On 10/04/13 11:24, Wouter Verhelst wrote: On 10-04-13 12:07, Raphael Hertzog wrote: +whitespace, everything after the first hash character (tt#/tt) whitespaces ? (with s) No, absolutely not. The word whitespace does not have a plural form, since it is not a noun (you cannot say a whitespace, for instance). I've mostly seen whitespace used as a mass noun, like water or sand: you can say whitespace is ignored or a sequence of whitespace, but not a whitespace or whitespaces, in the same way that it's correct to say some sand, a piece of sand or a cubic metre of sand, but not a sand or sands. (It's also an adjective: a whitespace character.) Right. I had a feeling that my statement about the grammatical reasons for my no wasn't entirely correct -- but at the very least I was sure about it not having a plural form :-) -- 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/516541d0.1050...@debian.org
Re: Bug#582109: debian-policy: document triggers where appropriate
On 10-04-13 18:19, Don Armstrong wrote: On Wed, 10 Apr 2013, Simon McVittie wrote: hat class=native-en_GB-speaker I've mostly seen whitespace used as a mass noun, like water or sand: you can say whitespace is ignored or a sequence of whitespace, but not a whitespace or whitespaces, in the same way that it's correct to say some sand, a piece of sand or a cubic metre of sand, but not a sand or sands. Slight nitpick: you can (almost) always refer to collections of mass nouns in a plural form. So whitespaces and sands are perfectly reasonable to use, but then they refer to multiple separate whitespace-containing areas, or multiple separate sand-containing areas. Ah, yes, but then you still wouldn't say whitespaces or sands without further qualification; you'd say something along the lines of Kara ben Nemsi rode his horse through the sands of Egypt -- i.e., the sands, rather than just sands. anyway, EOT for me now -- I'm not even a native English speaker. -- 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/51659c55.2000...@debian.org
Re: Bug#701081: debian-policy: mandate an encoding for filenames in binary packages
On 30-03-13 06:11, Charles Plessy wrote: Le Mon, Mar 25, 2013 at 01:32:50PM +0100, Wouter Verhelst a écrit : The fact that we don't have a solution (yet) doesn't mean we don't want a solution, nor does it mean we should give up. wontfix is for things that the maintainer disagrees is a problem; surely you don't think that is the right attitude here. While I can understand your desire to limit the number of open requests to the policy group, and even share it to some extent, I don't think you should close bugs just because immediate discussion doesn't find a solution. Hi Wouter, the problem with this bug (#701081) is that we do not even have an agreement on what the problem is. And without a problem, it is hard to find a solution. [...] Okay, fair enough. I still think it is wrong to close the bug in that situation, but given this explanation I understand the reasoning; and I am not a policy editor, you are ;-) -- 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/515a869a.6030...@debian.org
Re: Bug#688220: debian-policy: Typo in path to shlibs files in /var/lib/dpkg/info (8.6.4.1)
On 28-03-13 00:16, Charles Plessy wrote: I have corrected the typo in the Policy. Sorry Salvatore, I did not realise on time that your patch was a Git patch, so the commit is on my name, but you are properly thanked in the changelog and the commit message. git commit --amend --author Salvatore Bonaccorso car...@debian.org should fix that, *if* you haven't done any commit since then (and if you have, well, you know now for next time) -- 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/5153ea12.8060...@uter.be
Re: Bug#701081: debian-policy: mandate an encoding for filenames in binary packages
Hi Charles, On 24-03-13 12:01, Charles Plessy wrote: Given that this bug report asks for a policy about the encoding of filenames, doing nothing is equivalent to reject it. I therefore propose one more round of concertation, and if it is not conclusive, I will tag this bug wontfix and close it (we have 185 other bugs in the queue). I think that is a bad idea. Sometimes the right way forward is not immediately apparent, and giving the problem its due time will cause the solution to become obvious. The fact that we don't have a solution (yet) doesn't mean we don't want a solution, nor does it mean we should give up. wontfix is for things that the maintainer disagrees is a problem; surely you don't think that is the right attitude here. While I can understand your desire to limit the number of open requests to the policy group, and even share it to some extent, I don't think you should close bugs just because immediate discussion doesn't find a solution. -- 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/515043f2.9020...@uter.be
Policy for local packages?
Hi all, About a week ago, I gave a course at a customer about packaging Debian packages. While preparing and giving the course, I was reminded of something I'd been meaning to bring up before: 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. 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130121205206.gb29...@grep.be
Bug#587279: debian-policy: section 2.2.1 needs some tweaking
On Mon, Mar 12, 2012 at 06:19:47PM -0400, David Prévot wrote: Le 12/03/2012 13:44, Wouter Verhelst a écrit : On Sat, Feb 25, 2012 at 01:56:17AM +0100, Carsten Hey wrote: […] how a possible mechanism to let users choose between always prefer free packages and follow the maintainer's recommendation, even it a non-free package is preferred could look like. That's easy: Package: * Pin: release c=non-free Pin-Priority: 1 in a file in /etc/apt/preferences.d/ Please, don't provide such advice: that won't allow a non-free package to be updated automatically during a stable or security update. No, that's not correct. If a package is already installed but a newever version is available, then this will be upgraded if the priority is 1. It just won't be selected for installation automatically. This is how experimental works: packages in experimental have priority 1, so won't be installed automatically; but the will be upgraded if needs be. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- 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/20120313105433.ga4...@grep.be
Re: Bug#587279: debian-policy: section 2.2.1 needs some tweaking
On Sat, Feb 25, 2012 at 01:56:17AM +0100, Carsten Hey wrote: This reads like you ask if main | non-free should be allowed. In my opinion, the question should rather be if it must be main | non-free or if both, main | non-free and non-free | main, should be allowed and how a possible mechanism to let users choose between always prefer free packages and follow the maintainer's recommendation, even it a non-free package is preferred could look like. That's easy: Package: * Pin: release c=non-free Pin-Priority: 1 in a file in /etc/apt/preferences.d/ -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- 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/20120312174435.ga22...@grep.be
Re: [proposal] remove the requirement to compress documentation
On Wed, Feb 22, 2012 at 12:09:15AM +0100, Joerg Jaspert wrote: There's more than just my /usr. This system runs off a 160GB SSD, so 500MB is more like 0.5% of the available storage space here. 160GB is in the low end of the available storage of modern systems, and probably (gut feeling) about average of systems bought in the past few years (my three-year-old HP laptop came with a 160GB rotating disk). Make that 40GB, not 160GB. Thats about the small end of storage you get for new bought systems in the Office PC category. SSD. (and actually more than enough for that type). I said average, not small -- but at any rate, it's a bit besides the point. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- 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/20120222115157.ga4...@grep.be
Re: [proposal] remove the requirement to compress documentation
On Tue, Feb 21, 2012 at 09:01:42AM +0100, Raphael Hertzog wrote: On Tue, 21 Feb 2012, Wouter Verhelst wrote: On Mon, Feb 20, 2012 at 07:09:40PM +0100, Wouter Verhelst wrote: On Mon, Feb 20, 2012 at 06:02:50PM +0100, Bill Allombert wrote: Debian is used on small systems where users still like to have documentation, and support zlib compression is almost universal. I would not have any objection against a tool which would compress files upon installation for those users who want it. But I don't think having to compress files inside the .deb package buys us very much anymore. To be a bit more specific on this: such a tool could be implemented fairly trivially with a dpkg trigger. Just register a trigger that triggers on any file under /usr/share/doc, and have it call gzip --best on the files it is called with. This is a common misunderstanding with dpkg's file triggers. When the trigger is activated, you only know that something changed in /usr/share/doc but you don't know what changed. So it would be a rather costly operation to rescan all of /usr/share/doc/ just to compress the new files. Oh, hrm. yeah, scratch that then. Furthermore, just like Russ said, it's a very bad idea to change files installed by dpkg. If you change the filename, dpkg won't find the file when it has to remove the package. (Even if you had only to change the content, you'd break tools like debsums) True. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- 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/20120221084740.ga26...@grep.be
Re: [proposal] remove the requirement to compress documentation
On Mon, Feb 20, 2012 at 06:49:15PM +0100, Jakub Wilk wrote: * Bill Allombert bill.allomb...@math.u-bordeaux1.fr, 2012-02-20, 18:02: iceweasel handle compressed file fine Oh, does it? I just tried to open /usr/share/doc/ccache/changelog.html.gz and it gave me the following options: * Open with /bin/tar (default) * Save file I can't say I'm satisfied with any of them. It does if you set up a webserver and browse http://localhost/doc/, but that's a burden on the user. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- 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/20120220175652.gb5...@grep.be
Re: [proposal] remove the requirement to compress documentation
On Mon, Feb 20, 2012 at 06:02:50PM +0100, Bill Allombert wrote: On Mon, Feb 20, 2012 at 08:22:52AM +0100, Wouter Verhelst wrote: Hi, During a recent discussion on debian-devel about multiarch, it was shown that gzip does not always produce the exact same output from a given input file. Hello Wouter, While it was shown that removing the requirement to compress documentation would not solve the issue (i.e., the problem was larger than just the compressed files), To be honest, I am not sure why you are taking the trouble to bring it up, under those circumstances. Because I've long thought that compressing files is not a good idea; this just triggered me enough to come up with a proposal. I still think removing the requirement to compress files is a good thing to do. Rationale: - While I'm sure compressing files would have been a useful thing to do in the days of 500MB-harddisks, the same is no longer true for today's hundreds-of-gigabytes harddisks. A simple test[1] shows that the increase in diskspace is negligible in relation to today's disk sizes. 500MB is not negligible. This is 5% of /usr on your system, but this can be higher on other system with a different package set. There's more than just my /usr. This system runs off a 160GB SSD, so 500MB is more like 0.5% of the available storage space here. 160GB is in the low end of the available storage of modern systems, and probably (gut feeling) about average of systems bought in the past few years (my three-year-old HP laptop came with a 160GB rotating disk). People who use smaller disks are also likely to have less software installed[1], so the impact would probably remain around the same number. [1] At least I know that when my storage space runs out, my first reflex is to run aptitude and remove all those old and silly things that I installed once but don't really need anymore, rather than starting to see which parts of my homedirectory can be moved off to an external USB hard disk or some such. - In the cases where the increase in diskspace would be significant, i.e. in embedded systems, the best option is to use emdebian, which already routinely removes *all* documentation from the system as part of the modifications they make to Debian proper; so this change would not impact embedded users. - Compressing documentation files incurs an additional step on the user who wants to read said documentation. Yes, there is zless and zmore. However, there is no ziceweasel, zpdf-reader[2] or zgv. Even if such tools do exist, we would still require that users either know these tools exist and how to get them, or to decompress files before reading them. iceweasel handle compressed file fine Only if you go through some extra effort (and install some extra software -- why compress if you need to install extra software to read it?). and so does zxpdf. That is yet another tool that a user needs to know about. Another disadvantage of compressing tools (I forgot to mention this originally): referring to documentation gets clumsier; e.g., a hyperlink in an HTML file will probably become a dead link. As such, I believe the requirement to compress files is an anachronism that we should get rid of. I do not like removing a useful requirement in exchange for nothing. I would agree with that statement, except that I don't think compressing files is very useful anymore. Debian is used on small systems where users still like to have documentation, and support zlib compression is almost universal. I would not have any objection against a tool which would compress files upon installation for those users who want it. But I don't think having to compress files inside the .deb package buys us very much anymore. As to your remark about small systems: these are either going to be embedded systems (where the better option is to use emdebian, and then this is a non-issue), or very old and slow systems (in which case you really really don't want to be adding more processor requirements to users in order to allow them to read anything -- and I know what I'm talking about here, I do m68k stuff). -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- 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/20120220180940.gc5...@grep.be
Re: [proposal] remove the requirement to compress documentation
Package: debian-policy Version: 3.9.2 Severity: wishlist On Mon, Feb 20, 2012 at 09:17:16PM +0100, Iustin Pop wrote: On Mon, Feb 20, 2012 at 08:22:52AM +0100, Wouter Verhelst wrote: Hi, During a recent discussion on debian-devel about multiarch, it was shown that gzip does not always produce the exact same output from a given input file. While it was shown that removing the requirement to compress documentation would not solve the issue (i.e., the problem was larger than just the compressed files), I still think removing the requirement to compress files is a good thing to do. Rationale: - While I'm sure compressing files would have been a useful thing to do in the days of 500MB-harddisks, the same is no longer true for today's hundreds-of-gigabytes harddisks. A simple test[1] shows that the increase in diskspace is negligible in relation to today's disk sizes. - In the cases where the increase in diskspace would be significant, i.e. in embedded systems, the best option is to use emdebian, which already routinely removes *all* documentation from the system as part of the modifications they make to Debian proper; so this change would not impact embedded users. - Compressing documentation files incurs an additional step on the user who wants to read said documentation. Yes, there is zless and zmore. However, there is no ziceweasel, zpdf-reader[2] or zgv. Even if such tools do exist, we would still require that users either know these tools exist and how to get them, or to decompress files before reading them. As such, I believe the requirement to compress files is an anachronism that we should get rid of. Thoughts? Good idea, seconded. That makes three; while the proposal definitely needs more work, I think that makes it time to file a bug on this so it can be properly tracked. One thing I haven't talked about yet is man and info pages. While I feel very strongly that we shouldn't compress files under /usr/share/doc anymore, I don't feel as strongly about man and info pages. Yes, these are documentation as well; but since nobody reads man or info pages except through tools that all support transparant decompression, the question then becomes what sets them apart from other documentation. I guess the answer to that question is the fact that you start reading documentation under /usr/share/doc with a filename, whereas you start reading man or info pages with a keyword. As such, how this documentation is stored is a technical detail; not so when you need to use a filename. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- 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/20120220235142.gm4...@grep.be
Re: [proposal] remove the requirement to compress documentation
On Mon, Feb 20, 2012 at 07:09:40PM +0100, Wouter Verhelst wrote: On Mon, Feb 20, 2012 at 06:02:50PM +0100, Bill Allombert wrote: Debian is used on small systems where users still like to have documentation, and support zlib compression is almost universal. I would not have any objection against a tool which would compress files upon installation for those users who want it. But I don't think having to compress files inside the .deb package buys us very much anymore. To be a bit more specific on this: such a tool could be implemented fairly trivially with a dpkg trigger. Just register a trigger that triggers on any file under /usr/share/doc, and have it call gzip --best on the files it is called with. Would such a tool alleviate your concerns? -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- 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/20120220235351.gn4...@grep.be
[proposal] remove the requirement to compress documentation
Hi, During a recent discussion on debian-devel about multiarch, it was shown that gzip does not always produce the exact same output from a given input file. While it was shown that removing the requirement to compress documentation would not solve the issue (i.e., the problem was larger than just the compressed files), I still think removing the requirement to compress files is a good thing to do. Rationale: - While I'm sure compressing files would have been a useful thing to do in the days of 500MB-harddisks, the same is no longer true for today's hundreds-of-gigabytes harddisks. A simple test[1] shows that the increase in diskspace is negligible in relation to today's disk sizes. - In the cases where the increase in diskspace would be significant, i.e. in embedded systems, the best option is to use emdebian, which already routinely removes *all* documentation from the system as part of the modifications they make to Debian proper; so this change would not impact embedded users. - Compressing documentation files incurs an additional step on the user who wants to read said documentation. Yes, there is zless and zmore. However, there is no ziceweasel, zpdf-reader[2] or zgv. Even if such tools do exist, we would still require that users either know these tools exist and how to get them, or to decompress files before reading them. As such, I believe the requirement to compress files is an anachronism that we should get rid of. Thoughts? [1] http://lists.debian.org/debian-devel/2012/02/msg00340.html [2] Some PDF readers can transparently read compressed PDF files, but I don't think this is true for all such software. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a signature.asc Description: Digital signature
Re: re buildd's resolver and package's build deps
On Mon, Feb 28, 2011 at 07:12:00PM +, Roger Leigh wrote: On Mon, Feb 28, 2011 at 03:36:47PM +0100, Wouter Verhelst wrote: On Tue, Feb 22, 2011 at 05:08:18PM +, Roger Leigh wrote: This is correct. I was thinking about drafting a patch for Policy about this. Current Policy defines the allowed syntax for Build-Depends. It does not however, make any mention of existing conventions and best practices, which I feel should be addressed. The current internal build dependency resolver does not make any use of the alternative dependencies. It always picks the first. It was my understanding that there are some corner cases in which it would select the second: - where one build-dependency (indirectly) depends on a secondly-listed alternative, it could install the second. - sbuild will not worry about installing the first alternative if the second has already been installed. but I might be mistaken about one or both of the above. I'm not totally sure either, to be honest. The internal resolver code is horrible. Yeah, I know -- I've written a patch for experimental support once, and it took me several days just to figure out where to add two characters, or some such... It looks like it still has relics of manual source-deps entangled in there as well (but I don't dare to touch it since it will probably break horribly if I delete it). The alternatives processing is in Sbuild::InternalResolver::parse_one_srcdep and filter_dependencies, and it looks like it could well be OK with second alternatives if installed. Right, so I probably wasn't dreaming that up, then. Not that it matters all that much. At any rate, if a maintainer would wish to support backports easily (ever more relevant now that it's on debian.org systems), having alternative build-dependencies would make perfect sense; in those cases, sbuild would need to pick one set of dependencies for unstable, and the second set for backports. Agreed. Note that we now support strict 'first-only' alternatives handling with the 'apt' and 'aptitude' resolvers. See the notes for 0.60.0 and 0.60.1 pertaining to resolvers here: http://git.debian.org/?p=buildd-tools/sbuild.git;a=blob;f=NEWS;h=f4576f0e3b3c0fcd66abcd93898697246b9a;hb=HEAD We have made the alternative resolving configurable, so that you can use strict 'first only' or all alternatives. It defaults to 'first only', which will give resolution almost entirely like the internal resolver. Good. True, but the right solution for this problem is not to remove support for alternative build-dependencies; instead, policy should make it clear that when a package is built in unstable, no differences in alternatives should cause a change in functionality or support for file formats. Please see #614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions, which is the current proposal for documenting the existing behaviour (and it does preserve the ability for maintainers to use alternatives). Comments would be appreciated. I'll have a look. I would recommend keeping backports on a separate VCS branch rather than having a single unified package. I vehemently disagree with this recommendation. It works now, properly; what you suggest requires merging branches every time you wish to update the package. That introduces an extra maintenance burden for, IMHO, no good reason. I've been doing this on e.g. a 'lenny-backports' branch, and it's been a model of simplicity. I just 'git merge release-tag' and it's done except for updating the changelog (and fixing up the rare conflict). http://git.debian.org/?p=buildd-tools/schroot.git;a=shortlog;h=refs/heads/schroot-lenny-backport Certainly more reliable and convenient than doing things by hand. Sure. I'm not saying you shouldn't work on a separate branch if that works for you. But the mere fact that it works for you does not have to mean that it will work for everyone, and enforcing that for no particularly good reason does not sound like a good option to me. (anyway, that's moot, given your solution) [...] The need for concrete|virtual is a fundamental deficiency in our package management that's been unaddressed for years (see old -devel discussions). Pointer? The one I could find: http://lists.debian.org/debian-devel/2006/08/msg01281.html An ancient proposed solution (probably suboptimal): http://people.debian.org/~rleigh/virtual-policy_1.dsc AJ did say back then (though I can't find the mail, sorry), that he was working on a solution, but I don't know what happened to that. The main issue here is that every package with a concrete|virtual alternative dep is specifying its own idea of what the ideal concrete package should be. That is, each package is dictating what should be a system-wide policy, and this leads to a lack of uniformity because there's
Re: re buildd's resolver and package's build deps
Hi Roger, On Tue, Feb 22, 2011 at 05:08:18PM +, Roger Leigh wrote: On Mon, Feb 21, 2011 at 07:42:32PM -0600, Raphael Geissert wrote: I disagree here. Alternatives in build-* relationships *are* mentioned by policy. In fact, there's even an example in section 7.1. This is correct. I was thinking about drafting a patch for Policy about this. Current Policy defines the allowed syntax for Build-Depends. It does not however, make any mention of existing conventions and best practices, which I feel should be addressed. The current internal build dependency resolver does not make any use of the alternative dependencies. It always picks the first. It was my understanding that there are some corner cases in which it would select the second: - where one build-dependency (indirectly) depends on a secondly-listed alternative, it could install the second. - sbuild will not worry about installing the first alternative if the second has already been installed. but I might be mistaken about one or both of the above. Additionally, alternative build-dependencies are often virtual packages, to allow for future changes more easily. As a result: · other alternatives are untested (never used) I would suggest that they are less tested, rather than not tested at all. · we always have consistent builds (because there's only a single solution) · we have recommended against using alternative build dependencies since they were introduced; this was partly because sbuild didn't support them, but mainly because we want complete consistency I've never been aware of such a recommendation. At any rate, if a maintainer would wish to support backports easily (ever more relevant now that it's on debian.org systems), having alternative build-dependencies would make perfect sense; in those cases, sbuild would need to pick one set of dependencies for unstable, and the second set for backports. [...] There's also no stated guarantee *anywhere* (including release policy) that the package's build deps should be consistent, much less the result. I agree that the documentation is sorely lacking in this regard. It is, however, an unofficial and unwritten policy. The need for this is fairly self-explanatory: we don't want builds to vary. Taking one of php5's dependencies as an example: libdb-dev (= 4.7) | libdb4.8-dev | libdb4.6-dev This dependency permits building against no less than *three* different Berkeley DB versions. Given that these versions are typically incompatible, imagine if a new upload caused a version change. It could break all existing databases when the user upgrades and they are no longer readable. If could even be a downgrade. The same applies to any other libraries. True, but the right solution for this problem is not to remove support for alternative build-dependencies; instead, policy should make it clear that when a package is built in unstable, no differences in alternatives should cause a change in functionality or support for file formats. [...] Also, alternatives have been used ever since I joined the project for making backporting easier. Requiring stricter build-deps also affects that use case. This is one of the two non-broken use cases for alternatives (the other being arch-specific deps) I am aware of. However, given that the infrastructure has never supported alternative build-deps, I'm not sure how this is working out in practice. In order for it to not be broken, only one of the alternatives should be avilable in each suite you are targetting. I would recommend keeping backports on a separate VCS branch rather than having a single unified package. I vehemently disagree with this recommendation. It works now, properly; what you suggest requires merging branches every time you wish to update the package. That introduces an extra maintenance burden for, IMHO, no good reason. [...] Currently, 1294 packages use alternatives in build dependencies. These fall into these categories: · Standard alternative use in the form concrete|virtual, as used for normal deps on virtual packages. Is this sensible? Yes, because buildd hosts aren't the only systems used for building packages. The best example of that: · concrete|virtual libgl1-mesa-dev | libgl-dev libglu1-mesa-dev | libglu-dev The nvidia GL libraries conflict with mesagl. If you use the non-free nvidia driver, you cannot install libgl1-mesa-dev without removing your display driver. Removing the libgl-dev alternatives here, is a bad idea. Build-dependencies were originally created for the buildd hosts, and sbuild is still the main user of build-deps; so if something is happening which would break sbuild, then sure, that means we should change that. But it's important to remember that build deps aren't *just* used by sbuild. It is not unsensible to want to build a package on your local system; whenever that happens, having just a strict set
Bug#554194: ifupdown virtual package name and mass-filing (if accepted)
On Mon, Jan 18, 2010 at 01:56:17AM -0800, Steve Langasek wrote: On Sat, Jan 16, 2010 at 03:31:28PM +0100, Wouter Verhelst wrote: There was no further discussion on this item since the above date. FWIW, I for one hadn't commented up to now because I find that fundamentally, implementing a compatible commandline interface for ifup/ifdown and not implementing support for /etc/network/interfaces is precisely backwards, and I was waiting to see if anyone else would speak to this point. AFAICS, there are only two places in the system where other packages integrate by calling ifup/ifdown: /etc/init.d/networking, and /lib/udev/net.agent. The former ought to be all but obsoleted by the latter (N.B.: should, but isn't), and the latter could just as well be moved to the ifupdown package itself and a corresponding agent be provided by any conflicting packages. Indeed. In fact, I had assumed that that initscript was, indeed, part of the ifupdown package; so much so, in fact, that I hadn't even checked. Thanks for pointing that out. So the commandline ifup/ifdown interface is of little relevance, whereas the configuration state contained in /etc/network/interfaces is of vital importance to the operation of the system and I would expect anyone trying to replace ifupdown to handle this critical configuration migration issue. It's a fair point, but one I happen not to agree with. As an example, ifplugd has a default configuration that calls 'ifup' when it discovers that the MII reports a link. I think this is a valid case of something using the 'ifup' binary, and not something that needs to be migrated away (at least not until the daemon functionality of ipcfg has been implemented, which might take a while). That's a third example (added to your two above); I'm sure there are more. I think the use of ifup/ifdown as an interface to manage network interfaces (no pun intended) is more widespread than you seem to believe. Second, the main reason I chose not to support the /etc/network/interfaces at this phase is that I believe it is fundamentally limited in what it can support: it makes the assumption that whenver the user calls 'ifup something', we already know which interfaces we're going to be configuring. I specifically do not wish to support that assumption. Now of course I could extend the interfaces format to allow this, but I'm afraid that's going to be kludgy at best. That's why I started off with a different file format. Of course upgradeability is a major cause for concern, and if ipcfg is ever going to replace ifupdown then at one point or another I'll have to deal with this issue. I'm not sure yet how I'll be doing that; it could be by way of a perl script to convert an interfaces file to an ipcfg config file, or it could be by way of an alternate parser. It's not something I want to deal with now, however -- first things first; while it's in experimental now, I don't think it'll be ready for unstable in time for squeeze -- I'd even be surprised if it was ready for prime time in time for squeeze+1. Third, I do not see any good reason why any configuration file format should be part of a described interface. If another software package wishes to do something with network interfaces consistently with ifup's configuration, then that package should not try to read ifup's config file -- it should be calling ifup with the necessary parameters to accomplish what it needs to do. We might need to extend the interface to allow querying of available configuration to allow this better, but that's about it. If another package wishes to write ifup's configuration file, then either it is doing something utterly wrong and against policy, or it is a user configuration agent that needs to know much about the inner workings of the particular ifup implementation it is working for anyway, and has no business depending on a virtual package. Regards, -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554194: ifupdown virtual package name and mass-filing (if accepted)
On Sat, Jan 16, 2010 at 06:09:19PM +0100, Bill Allombert wrote: On Sat, Jan 16, 2010 at 03:31:28PM +0100, Wouter Verhelst wrote: On Thu, Nov 05, 2009 at 09:54:37AM +0100, martin f krafft wrote: [...response that is not very relevant to this mail...] There was no further discussion on this item since the above date. Since I've recently uploaded ipcfg, I'd like this to be finalized. It currently uses 'ifupdown' as the name to conflict/replace/provide, but I don't consider that to be a particularly good idea. I'm suggesting that the package name 'network-config-tool' be described as a tool for a package providing 'ifup' and 'ifdown' binaries. These should provide the following interface: - support 'ifup interface name' or 'ifdown interface name' to bring an interface up or down, consistently with configuration, and exit with non-zero if either operation fails. Is ifup eth0=foo supported ? Should be fairly easy to add that to ipcfg, which might be a good idea. Let's make that part of the interface, too. - may provide a virtual interface name that does not map to an actual physical interface name, but instead uses internal logic to decide what to do. Is not there a namespace issues wrt other interface that should be clarified ? There are namespace issues, but I don't think they should be explained in the interface specification; the tools should do so in their documentation. This is a may part of the specification, not a should. - ifup and ifdown should support a '-a' or '--all' option to configure or deconfigure 'all' interfaces. Here, 'all' is defined as 'all interfaces for which the tool's configuration defines that they should be brought up or down with the -a option'. OK. - ifup and ifdown should support a '-v' or '--verbose' option to aid in debugging. This requirement does not feel necessary. If a tool calls ifup, it may wish to call it with -v to provide some output to the user should bringing the interface up fail, which can be useful. Perhaps it should be clarified that the output format of -v is undefined. - ifup and ifdown should support hook scripts in /etc/network/if-*.d: - the tool should provide a way for the user to set configuration values through environment variables, the name of which start with IF_ - the tool should provide PHASE and MODE variables, describing what we're trying to do - (since I could not find a formal specification of the if-*.d hook script interface, I may have missed some things; if so, please let me know) Obviously this also needs the IFACE= environment variable, defining the interface on which we work. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554194: ifupdown virtual package name and mass-filing (if accepted)
On Thu, Nov 05, 2009 at 09:54:37AM +0100, martin f krafft wrote: [...response that is not very relevant to this mail...] There was no further discussion on this item since the above date. Since I've recently uploaded ipcfg, I'd like this to be finalized. It currently uses 'ifupdown' as the name to conflict/replace/provide, but I don't consider that to be a particularly good idea. I'm suggesting that the package name 'network-config-tool' be described as a tool for a package providing 'ifup' and 'ifdown' binaries. These should provide the following interface: - support 'ifup interface name' or 'ifdown interface name' to bring an interface up or down, consistently with configuration, and exit with non-zero if either operation fails. - may provide a virtual interface name that does not map to an actual physical interface name, but instead uses internal logic to decide what to do. - ifup and ifdown should support a '-a' or '--all' option to configure or deconfigure 'all' interfaces. Here, 'all' is defined as 'all interfaces for which the tool's configuration defines that they should be brought up or down with the -a option'. - ifup and ifdown should support a '-v' or '--verbose' option to aid in debugging. - ifup and ifdown should support hook scripts in /etc/network/if-*.d: - the tool should provide a way for the user to set configuration values through environment variables, the name of which start with IF_ - the tool should provide PHASE and MODE variables, describing what we're trying to do - (since I could not find a formal specification of the if-*.d hook script interface, I may have missed some things; if so, please let me know) Comments are welcome. [aj: I haven't seen any comment from you on this, and would like to make sure that you're comfortable with whatever interface we come up with -- please comment.] -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [PATCH 1/1] [bug556972-srivasta]: Explicitly allow /selinux and /sys as FHS exceptions
Hi, I'm a bit late to the party, but: On Fri, Nov 20, 2009 at 12:33:50PM -0600, Manoj Srivastava wrote: This patch explicitly allows /sys and /selinux as additional directories int he root file system allowed under the policy. We should probably add /spu to that list, which is where spufs is traditionally mounted on CBEA machines (Cell Broadcast Engine Architecture) to manage (communication with) the Synergistic Processing Elements. Without this pseudofilesystem, interaction with the SPEs is impossible. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: makedev is now priority extra
On Mon, Oct 05, 2009 at 08:11:57AM +0200, Luk Claes wrote: Manoj Srivastava wrote: Actually, udev, while nice, is optional, and I think I have read reports of admins opting _not_ to have udev on the system, so in some cases one may have systems without udev and with MAKEDEV. Policy should try to support this, if we can. It's only optional in theory as if you don't use it you're totally on your own. Er, what do you base that statement on? -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554194: ifupdown virtual package name and mass-filing (if accepted)
On Wed, Nov 04, 2009 at 10:52:00AM +0100, martin f krafft wrote: also sprach Wouter Verhelst wou...@debian.org [2009.11.04.0230 +0100]: Since to me the point of this exercise is so that I can usefully put ipcfg into the archive, and since ipcfg does not actually support /etc/network/interfaces, I'd say that should not be part of the interface. Hehe, but interface definitions usually describe the status quo from the users' perspective, not the state of development of a new tool aiming interface compatibility. Gosh, I wish the ISO 9000 specs worked that way! ;) That'd be nice, wouldn't it? ;-) It *is* questionable how mucn /e/n/i is part of the interface though. Indeed, and that's really my main point. I could also have said that I don't want to be command-line compatible because it's too much work, but it's *not* questionable how much *that* is part of the interface, so yes, that I do intend to be compatbile with. A config file format is something else; and since, first, Debian packages are not supposed to modify eachother's configuration files; and, second, ifupdown makes the relevant values in its configuration file available through environment variables (so that ifupdown plugins don't have to parse the ifupdown config file), I think it's not unreasonable to make the config file format not part of the interface. Since that would make it easier for me (I'm not aiming for ifupdown config file compatibility, at all), I'd prefer it that way. Of course we could define an interface that requires things to be drop-in replacements for ifupdown, but then I can't use it, and I don't think there's much point in defining a virtual package that ifupdown (and ifupdown alone) could put in its Provides: header. Instead, what I'm trying to accomplish is to come up with an interface that can be used by packages which want to mangle the state of network interfaces without actually caring much about how, specifically, it's done. Since I don't think it can be said that you don't care about that if you care about a config file format, I think it's fair to exclude that from this interface. I do have code to support /etc/network/if-*.d/*, though I consider that a temporary hack so that the code would be useful sooner rather than later. It also doesn't work yet ;-) Okay. I definitely think the hooks are part of the interface that we need to support in any network configuration tool. I'm not sure I fully agree with that, but since the code is there, and since it's a plugin that can be disabled, I don't actually care all that much about the issue. So yeah, that can be kept in for all I care :-) Especially the hooks are integral to a lot of other packages that depend on ifupdown. I'd say that's part of any Debian network-config-tool interface. Basically, the interface that I'd like to see is tool that can bring up a given interface as configured by the user. E.g., if ifplugd calls ifup eth0, it should not care which implementation of ifup is being called to actually bring the interface up. Yes. But there are tools that will call it with --verbose, or with --all. I think we agree anyway. Supporting --all should not be hard. Basically, I just need to map --all to ifup auto or ifdown all internally. That's a no-brainer. Supporting --verbose might be a different issue, and depending on how it's used, might be a bad idea to support from ipcfg. If the --verbose output is just used to log stuff or give a user more information, then that doesn't matter, and I intend to have a --verbose output option, anyhow. If these commands are parsed and executed somewhere else, it might be possible to make sure the --verbose option does some output that these tools can parse, too, but it's an edge case. If the tools try to parse that information to figure out how to bring an interface down again later or some such, then they're really exploiting the fact that ifupdown exposes much about its internals, and it might be said that the statement that they don't care about how it's done is no longer true for these tools. Depends: (...), ifupdown (= 0.6.8+nmu3) | network-config-tool, (...) because this is a matter of we need at least this version of ifupdown to work properly rather than we absolutely need ifupdown; after all, it's ifupdown or ipcfg that calls dhclient, not the other way around. That does seem weird and should not be needed, indeed. Actually, I think Andrew should have made that a versioned Conflicts: rather than a versioned Depends:. I vaguely remember him blogging about ISC DHCP4 not working properly with ifupdown and that the latter needed patches. I guess this version is the first one where these patches are included. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html
Bug#554194: ifupdown virtual package name and mass-filing (if accepted)
On Tue, Nov 03, 2009 at 08:02:31PM +0100, martin f krafft wrote: also sprach Wouter Verhelst w...@uter.be [2009.11.03.1915 +0100]: As such, I'd like to propose the addition of a virtual package name, network-config-tool, that would be used for any package which provides /sbin/ifup and /sbin/ifdown binaries. You'll need to be a lot more specific on the interface definition. Do they have to be binaries? Do they have to take the same flags, e.g. --force and --all? With 'binaries', I meant 'executables'. Whether they're scripts or compiled programs doesn't actually matter to me. Sorry for the confusion. The goal is indeed for ipcfg to become command-line compatible with ifupdown, though I'm not there yet. What about /etc/network/interfaces and /etc/network/if-*.d/*? Since to me the point of this exercise is so that I can usefully put ipcfg into the archive, and since ipcfg does not actually support /etc/network/interfaces, I'd say that should not be part of the interface. I do have code to support /etc/network/if-*.d/*, though I consider that a temporary hack so that the code would be useful sooner rather than later. It also doesn't work yet ;-) (occasionally, that's the only reason why it's not been uploaded yet) Especially the hooks are integral to a lot of other packages that depend on ifupdown. I'd say that's part of any Debian network-config-tool interface. Basically, the interface that I'd like to see is tool that can bring up a given interface as configured by the user. E.g., if ifplugd calls ifup eth0, it should not care which implementation of ifup is being called to actually bring the interface up. However, it should also be sensible to change the Depends: line in isc-dhcp-client from Depends: (...), ifupdown (= 0.6.8+nmu3), (...) to Depends: (...), ifupdown (= 0.6.8+nmu3) | network-config-tool, (...) because this is a matter of we need at least this version of ifupdown to work properly rather than we absolutely need ifupdown; after all, it's ifupdown or ipcfg that calls dhclient, not the other way around. Of course there are some packages that just don't make sense without ifupdown, and there it's fine to not add the network-config-tool alternative. One example of this is guessnet; ipcfg has a much more flexible way of doing what guessnet does (in fact it's a design goal), and therefore does not have support for ifupdown's mapping scripts that guessnet uses. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Bug#554194: ifupdown virtual package name and mass-filing (if accepted)
Package: debian-policy Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org, ifupd...@packages.debian.org Hi all, As you may or may not know, I've been working on an alternative implementation of ifup and ifdown, which I call 'ipcfg', for a few months now[1]. The code is now nearly at the point where I'll be using it on my own laptop, at which point I intend to upload it to experimental, too. Since it intends to be an ifupdown replacement, and indeed provides ifup and ifdown binaries, it will have to conflict with ifupdown. As a result, I'll have to make sure that it can be installed as an alternative to it, by way of a virtual package name. As such, I'd like to propose the addition of a virtual package name, network-config-tool, that would be used for any package which provides /sbin/ifup and /sbin/ifdown binaries. If accepted, I will also be mass-filing wishlist bugs on packages that currently depend on ifupdown only because they need to be able to use ifup and ifdown, or because they have a versioned dependency on ifupdown to avoid certain bugs, with a request to provide a network-config-tool alternative. Thoughts, comments? [1] The announcement and some more detail can be found at http://grep.be/blog/en/computer/code/ipcfg/announce -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Changes in the maintenance of the Developers Reference
On Mon, Sep 21, 2009 at 01:40:51PM +0200, Bill Allombert wrote: Debian Policy has a more formal process than developers-reference and I am concerned that mixing both discussions on the same channel would cause confusion. debian-de...@l.d.o could be a better channel for the developers-reference discussions, though with the downside of yet more outside traffic than debian-policy. The whole point of moving the devref to -policy@ was so that policy amendments that belong more in the devref (and vice versa) could easily be redirected. That advantage is lost if devref discussions were to be moved to -de...@. If you fear there will be confusion, it's probably best to make some minor changes to the devref process so that there will not be confusion. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544981: debian-policy: Discourage native packages that are not tightly specific to Debian
Hi, (sorry, missed this mail) On Sun, Sep 13, 2009 at 08:38:58PM +0200, Emilio Pozuelo Monfort wrote: Emilio Pozuelo Monfort wrote: Given the recent thread in debian-devel[1], I think we should document in policy that packages that are not tightly related to Debian shouldn't be native. So to move this on, how about only recommending it? Wouter, would you be happy with that? I guess you mean 'discouraging' rather than 'recommending' ;-) Sure, that's perfectly fine. I do think a discouraging remark in either policy or the devref, with or without a list of downsides of making a package native, is perfectly okay. After all, there /are/ downsides, and it's probably best to inform those who are thinking about it about those downsides. However, if a well-informed person knows what he's getting himself into, and decides that in their particular case making a package native is the right thing to do, I don't see why this would cause any problems. I'm not sure whether this should be in policy or in devref or somewhere else... If we just put a recommendation, I guess we don't really need to draw a line, but if that makes this better for devref and not policy, say so and I'll reassign. What do people think? My gut feeling says the devref, but I'd be happy either way. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544981: debian-policy: Discourage native packages that are not tightly specific to Debian
On Sat, Sep 05, 2009 at 01:55:09PM -0700, Steve Langasek wrote: Maybe I would be happier about dealing with native packages if there was a clear policy that packaging software as native implies that any DD is allowed to release a new upstream version of the software. :-) That would seem obvious to me, in fact. If a native package is NMU'ed, the only proper way to upload it is to upload a native package with a proper version suffix. Anything else could be said to fall afoul of the must not introduce packaging changes requirement of an NMU. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544981: debian-policy: Discourage native packages that are not tightly specific to Debian
On Fri, Sep 04, 2009 at 08:26:10PM +0200, Luk Claes wrote: Wouter Verhelst wrote: Given the recent thread in debian-devel[1], I think we should document in policy that packages that are not tightly related to Debian shouldn't be native. *sigh* So I spent a whole subthread trying to explain that I think this is *not* true, and seemed to get consensus on that, and now you want to get this into policy? Consensus is a big word, you managed to get people agree that if maintainers really considered all the downsides even our complaints from time to time that it would be acceptable... Why, yes, indeed, that's what I'm saying: that there seemed to be consensus on the fact that it is acceptable if people do indeed consider the downsides; that the shouldn't be native statement is wrong. Gee. Whether or not a native package makes sense should be the maintainer's prerogative, not decided by policy. As I said in the thread on -devel, there can be good reasons for making a package native. E.g., the maintainer doesn't have to deal with two releases (one upstream and one for debian) for every code change, but can just do one; there is immediate use of a translation team; releases are at least tested on Debian's architectures when they are released; etc. When using a non-native package, the maintainer does not have to do any separate release as the upstream tarball is in orig.tar.gz True. However, there will be no significant difference between making the package native or not in that case, IMHO. The translation team focuses on native packages (next to other Debian specific translation), because it does not have the resources to do all of it and native packages are considered Debian specific... so this is actually in some kind abusing the translation team if the package does not have to be native. Hmm. It could be seen that way, I guess. There are also obvious downsides to doing so, and it's probably a good idea to document these somewhere (though I doubt policy is the place for that; this is more something for the devref). However, outright claiming that it should not be done, will a) make a bunch of packages insta-buggy (which is bad, as far as policy is concerned), and b) is not the right thing to do, IMO. They are already buggy IMHO. Perhaps, but that does not mean that they in fact are. It has been okay for quite a while to do this, and several packages are in fact doing so; changing policy does make them insta-buggy. What I'd like to see before I would support this proposal (or anything like it), is how exactly the practice of releasing non-Debian-specific software as native packages is causing harm to either Debian, or the greater free software community as a whole; since I don't think it does, and I don't think we should forbid a practice which may make a maintainer's workflow easier if it is indeed harmless. In other words: what kind of problems do you think this will cause that have an effect on anyone *but* the maintainer? As said, I agree that documenting the problems with maintaining a package natively is a good thing to do, so that anyone thinking about going down that road can make an informed decision; but that is a far cry from what's being proposed here. Sure, if something is released as a native package, that does mean that people repackaging the software for other distributions may want to skip a few releases now and then -- but I do not see how that is any different from, say, the vim release model, where packagers may want to collect a few patches before uploading a new package, rather than uploading a new package every time Bram releases a patch (which happens about every other day or some such, AIUI). Sure, maintaining software as a native package does introduce the requirement that the other-distribution-packagers know what they're doing, and that they keep up with development with the Debian developer who maintains the package; but then I would hope they would be doing that anyhow. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544981: debian-policy: Discourage native packages that are not tightly specific to Debian
On Fri, Sep 04, 2009 at 10:56:43AM +0200, Emilio Pozuelo Monfort wrote: Package: debian-policy Version: 3.8.3.0 Severity: wishlist Hi, Given the recent thread in debian-devel[1], I think we should document in policy that packages that are not tightly related to Debian shouldn't be native. *sigh* So I spent a whole subthread trying to explain that I think this is *not* true, and seemed to get consensus on that, and now you want to get this into policy? Gee. Whether or not a native package makes sense should be the maintainer's prerogative, not decided by policy. As I said in the thread on -devel, there can be good reasons for making a package native. E.g., the maintainer doesn't have to deal with two releases (one upstream and one for debian) for every code change, but can just do one; there is immediate use of a translation team; releases are at least tested on Debian's architectures when they are released; etc. There are also obvious downsides to doing so, and it's probably a good idea to document these somewhere (though I doubt policy is the place for that; this is more something for the devref). However, outright claiming that it should not be done, will a) make a bunch of packages insta-buggy (which is bad, as far as policy is concerned), and b) is not the right thing to do, IMO. The motivations for discouraging native packages not Debian specific are that it makes it harder for other parties to make advantage of it. While I agree that there are downsides to non-debian specific native packages, I disagree that this is a correct example: For example, they would find new upstream releases that fixed Debian packaging bugs, or that were NMUs. They can perfectly well ignore those. Also, where should they report bugs? In bugs.debian.org? Yes, why not? Native packages make sense when the package is pretty much only useful for Debian (and Debian derivatives), e.g. dpkg or apt, but not for unrelated packages. They can make sense, and it should be the maintainer's prerogative to make that decision. Having a package be a native package when it is not Debian specific does not harm either Debian or the Free Software community at large; it only influences the workflow of the Debian maintainer, and that of non-Debian packagers of the software, if any. It is okay to point out what the effect will be of making a package native, so that a maintainer knows what he's getting him- or herself into. It is not okay to force a particular workflow on a maintainer just because *you* think it's not a good workflow. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543417: README.source patch system documentation requirements considered harmful
On Mon, Aug 24, 2009 at 10:33:14PM +0100, Chris Lamb wrote: Package: debian-policy Version: 3.8.3.0 Hi Policy hackers. I feel there is a problem with §4.14 (Source package handling: debian/README.source) that is a little harmful at present. Basically, I feel that assuming that all packages that use a patch system require a README.source is damaging the concept of README.source - as the archive grows more boilerplate descriptions on how to invoke quilt et al, I fear maintainers will simply not bother to consult this file when examining a package. I've been walking over README.source files a while ago, and given the proliferation of just copies of /usr/share/doc/quilt/README.source (et al), I understand your concerns and share them. I was actually planning to come up with some proposal or other once I'd finished looking at the README.source files, but whatever :-) This is particularly unfortunate as, not only can the file be extremely useful, I fear it will fuel a cycle of maintainers not updating the file with information as it does not get read anymore. Besides, the concept of boilerplate is hardly anthemic in Debian. If the motivation behind README.source is to highlight non-trivial packaging, then many packages can be presented that are trivial dispite using a patch system. My own conclusion is that the adoption of dpatch or quilt is so common that the skills for it may be assumed. To get things rolling, I propose that we temper: | This explanation should include specific commands and mention any | additional required Debian packages. It should not assume familiarity | with any specific Debian packaging system or patch management tools. ... with something subjective like any non-standard Debian packaging system. This would still ask maintainers to document the parts of their packages that would be unfamiliar to most developers, whilst avoiding maintainers including essays on how to invoke pbuilder and other nonsense. Whilst using a subjective like this isn't desirable, it does avoid having to enumerate specific programs that are exempt from explanation, which doesn't really smell right for the Policy. Precicely because you're doing subjective things here, I'm not convinced that using this wording is a good plan. Thoughts? I would instead suggest changing the next paragraph to something like the following: ``In case a package uses a build system for which documentation sufficient to satisfy this requirement exists in a file installed by one of the package's build dependencies, this file should be referred to from the README.source file, rather than copied into it.'' currently, this paragraph says: This explanation may refer to a documentation file installed by one of the package's build dependencies provided that the referenced documentation clearly explains these tasks and is not a general reference manual. Such phrasing will result in README.source files saying This package uses quilt, as documented in /usr/share/doc/quilt/README.source which can be safely ignored if the person doing the NMU is already familiar with quilt. However, if the package's README.source says This package uses quilt, mostly as documented in /usr/share/doc/quilt/README.source except that we do foo in place of bar Then this will easily trigger alarm bells to anyone doing an NMU that something out of the ordinary is happening here, and that they need to look out for that. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Bug#518199: debian-policy: virtual package names for doom-related packages
On Thu, Mar 05, 2009 at 11:03:57AM +0100, Giacomo A. Catenazzi wrote:
Jon Dowland wrote:
A brief explanation as to their meaning. Doom games are
divided into engine and world-resource components. The
former is captured by 'doom-engine'.
I don't understand why we need a 'doom-engine' virtual package.
[i.e.: avoid circular dependencies].
IMHO, a user will select an engine, not data.
I do not think so. The game data defines what game you play; the engine
defines _how_ you play it. Personally, I couldn't care less how exactly
a game is run on my system, as long as it is a game I like. IOW, the
data is what the user will choose, not the engine.
The latter is covered
by two different names, 'boom-wad' and 'doom-wad'.
I'm confused. A single virtual package ('doom-engine')
should handle two incompatibles engines?
No, boom-wad and doom-wad are the data packages. Doom is the original
game from id Software; boom is a fully-free set of data to implement a
different game (with the same engine).
--
Lo-lan-do Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: gnome, kde, xfce use non-policy main menu
On Sat, Jul 05, 2008 at 03:15:28AM -0500, William Pitcock wrote: Hi, On Sat, 2008-07-05 at 02:42 -0400, Daniel Dickinson wrote: For discussion: Gnome, KDE, and XFCE are the the top three desktops used in debian and cover most users of desktops in debian. They all use xdg .desktop-based menus as their main menu. xdg .desktop-based menus are not covered by policy. Honestly, policy really needs to be updated to use the XDG standards menu spec, and every WM at this point really should be using them for their menus. I think the debian-menu system should be seen as legacy, since it has been replaced with a standard used and supported by many upstreams and many other distros. However, there's a few places where debian-menu is a better solution though. (It can be used to build menus for many WMs which do not support XDG, but honestly, do we need all these WMs?) First of all: Yes, we do. Personally, I prefer not to use one of those 'desktop environment' thingies, since they annoy me. One of the main reasons why people use Linux is choice; we should give them that choice, not take it away and give users a pre-chewed monocultural environment (if you want that, go to Windows, MacOS, or Ubuntu). Second: XDG has less features than debian-menu currently does. For instance, unless I'm mistaken it's not possible to specify in an XDG .desktop file that a particular application is a curses or similar application that requires an xterm or some such, which is possible with menu. Due to this feature, it's also possible to have a package like pdmenu for non-graphical systems. Another solution would be to make debian-menu build .desktop entries for the menu in the main menu namespace and not the 'Debian' namespace; this seems like the easiest solution. The separation of a Debian menu and a desktop menu has been seen by some as a feature. I remember a post on Planet Debian by one of the GNOME maintainers (although I don't recall who it was) who explicitly said that he would not like to see non-GNOME applications in the GNOME menu but outside the Debian section. It is not unreasonable to state that it may be confusing for people to have a menu containing both GNOME and non-GNOME applications on a shared system; after all, different UI toolkits often have different UI guidelines and concepts; mixing those is not necessarily a good idea. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426877: dpkg: Option --oknodo should be the default behaviour for start-stop-daemon (LSB specs)
On Thu, Jul 03, 2008 at 11:02:13PM +0200, Iñaki Baz Castillo wrote: I think being LSB compliant is good for Debian. That may be so; but changing a long-standing interface with no migration is /not/ good for Debian. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#250202: debian/README.source file for packages with non-trivial source
On Tue, Jan 08, 2008 at 12:36:07PM -0800, Russ Allbery wrote: Jörg Sommer [EMAIL PROTECTED] writes: The rest looks good and I agree that such a source is useful, but it should also be allowed to refer to a central document like /u/s/d/dpatch/README.source. I expect that many README.source look the same. I don't think that needs any change to the above wording. If README.source refers to another existing file that documents those things, that seems to me to satisfy the above. Although I suppose we could explicitly add something like The instructions may refer to a documentation file installed by one of the package build dependencies, provided that it clearly explains these tasks and isn't a general reference manual. That seems like a good idea, actually; not because I expect people won't refer to other documents in the absense of such a clause, but rather because I feel it to be quite likely that they _will_ refer to general reference manuals otherwise. Thanks, -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#250202: debian/README.source file for packages with non-trivial source
Hi Russ, First, thanks for your great work on this bug. On Tue, Jan 01, 2008 at 10:54:06PM -0800, Russ Allbery wrote: This is the last Policy bug I had tagged as wording. It started with a proposal for a README.source file documenting how to do things with a package that uses a non-trivial source format, and then expanded into standardizing debian/rules targets for doing various things. Having reviewed the entire bug thread, I think there are a few misconceptions and a few different cases mingled together, so I'm going to attempt a summary. The original concern was being able to unpack a Debian source package and immediately start patching it, with a goal of creating a modified source package (for local modifications, security fixes, RC bug fixes, or what have you). I think that sums it up quite right, yeah :) Among the source package formats in Debian, I know of two possible situations: [...summary of patch systems snipped...] Now, I think that everyone (possibly except Marco) agrees with the basic idea of providing a README.source file explaining how to deal with a package that has a non-trivial source layout. In particular, I think someone needs to know how to do all of the following: 1. Generate the fully patched sources, the sources in the state in which they'll be built, so that one can check to see if problems have been patched, look at the source, and so forth. 2. Add a new patch to the build process (including any special techniques to use to generate the patch if there's an easier tool than recursive diff from an unmodified package and the like). 3. Remove an existing patch from the build process. 4. Ideally, explain how to upgrade the package to a new upstream version, although this should probably be optional. However, when we get into standardizing targets, this gets a lot murkier. I think the discussion above makes it clear that the only thing that we can really address with a target is point 1 above. For all of the systems, in the general case of modifications that overlap with existing patches, I don't think we can provide targets that do 2. 3 and 4 are obviously outside what a target can do. Yes, that seems correct. I hadn't thought of that problem, actually, but now that you mention it, I don't think there are ways of making that easy. In short, as you show, sticking to just adding one or more optional targets to debian/rules isn't going to cut it. Accordingly, I think moving forward with specifying a README.source file that explains the above three or four points is something we can reach consensus on. I'm not as sure about standardizing a target for 1 (setup, unpack, and patch are all currently in use), but I suppose that we could standardize on patched. This does raise insta-buggy issues since existing packages don't provide that target. However, I don't think it's going to work to say that after running some target, people should be able to make modifications and run dpkg-buildpackage and expect to have that work. In each case, it looks like there are cases where that isn't going to work, and I don't think it's viable to say that those patch systems can't be used. Makes sense. So, finally, I propose the following patch: --- orig/policy.sgml +++ mod/policy.sgml @@ -1926,6 +1926,19 @@ possible is a good idea. /p /item + + tagttpatched/tt (optional)/tag + item + p + This target performs whatever additional actions are + required to make the source ready for editing (unpacking + additional upstream archives, applying patches, etc.). + It is recommended to be implemented for any package where + ttdpkg-source -x/tt does not result in source ready + for additional modification. See + ref id=readmesource. + /p + /item /taglist p @@ -2076,6 +2089,50 @@ the file to the list in filedebian/files/file./p /sect + sect + headingSource package handling: + filedebian/README.source/file/heading + + p + If running prgndpkg-source -x/prgn on a source package + doesn't produce the source of the package, ready for editing, + and allow one to make changes and run + prngdpkg-buildpackage/prgn to produce a modified package ---^ Seems you've missed a there. + without taking any additional steps, creating a + filedebian/README.source/file documentation file is + recommended. This file should explain how to do all of the + following: + enumlist + itemGenerate the fully patched source, in a form ready for + editing, that would be built to create Debian + packages. Doing this with a ttpatched/tt target in + filedebian/rules/file is
Re: Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Wed, Aug 22, 2007 at 12:07:50PM -0700, Ben Pfaff wrote: Russ Allbery [EMAIL PROTECTED] writes: Bill Allombert [EMAIL PROTECTED] writes: I find the wording convenience copy of library from other software packages much more telling than convenience copy of code from other software packages that could be misinterpreted. For example, a lot of packages include a convenience copy of scripts part of automake (install-sh, depcomp, etc.). The sentence Debian packages should not make use of these convenience copies. seems to imply that they should not be used. Bleh. That's a valid point and I'm not sure how to deal with it without going back to the previous wording. One possible distinction is that in the Automake case, Automake itself encourages distribution of convenience copies of parts of itself. That is, it's the software that is copied, not the software that is making use of the convenience copies, that is encouraging people to make and use convenience copies. Yes. This could be written like ... exceptions to this rule include tools whose normal use case includes creating convenience copies, such as is the case for the GNU autotools or some such. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#209008: parallel building: DEB_BUILD_OPTIONS or DEB_BUILD_OPTIONS_PARALLEL
On Fri, Jul 27, 2007 at 04:56:14PM +0200, Matthias Klose wrote: - What to do if that option is not present? Should a package be allowed to build in parallel anyway, determing the number of processes itself, or should it be a sequential build? I think it should behave as is currently required then; that is to say, make it a sequential build. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#209008: debian-policy: [PROPOSAL] common interface for parallel building in DEB_BUILD_OPTIONS
On Wed, Mar 21, 2007 at 05:52:05AM +0200, Guillem Jover wrote: Personally I'd favour DEB_BUILD_OPTIONS_PARALLEL. Yes, I'll second that. It makes no sense at all to try to have the package predict how much memory it will need for the build; this amount of memory will be different depending on the architecture, the exact versions of build-dependencies that are in use, and a gazillion other unpredictable variables. The only person able to figure out which values are sane and which values aren't is the person running the build, if only by trial and error. The best anyone else can do is an educated guess, which is not something I would like in my packages. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401173: base-file: include GFDL and more licences in /usr/share/common-licenses/
On Fri, Dec 01, 2006 at 12:54:32PM -0800, Russ Allbery wrote: On Fri, 1 Dec 2006, Jari Aalto wrote: SUGGESTION Please add more standard license texts in the directory. Like: - GFDL - MIT/X license - Apache License - PHP License - http://creativecommons.org/ (when DFSG ready) I agree with the proposal to add the GFDL and Apache 2.0 licenses; they're already used by multiple packages and would save copyright file length and duplication. (Although I can see an argument against adding the GFDL because not all of its provisions are DFSG-free.) I wouldn't mind adding the SFDL if/when it becomes definite... The MIT/X license cannot be handled in this way. It includes varient text (the name of the organization) that changes in each license. It will have to continue to live in each individual copyright file. I have no opinion on the other two. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy (was: First draft of review of policy must usage)
On Sun, Nov 05, 2006 at 07:41:40PM -0800, Russ Allbery wrote: Russ Allbery [EMAIL PROTECTED] writes: Manoj Srivastava [EMAIL PROTECTED] writes: This flows from the Release policy. Not specifying /bin/bash in scripts is not considered a RC bug. I can try to propose better language for this. I think that using pure bash-specific constructs not found in dash in /bin/sh scripts should actually be an RC bug, but using test -a or test -o should not. I think we need to say that /bin/sh scripts are permitted to use POSIX shell capabilities plus a short list of additional capabilities that everything other than posh also implement. Here's a proposed patch. What do people think about this approach? [...] It looks good to me. Perhaps it would be nice if the policy would mention that the use of non-POSIX constructs should be avoided if possible, but I don't think it's important either way. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First draft of review of policy must usage
On Fri, Oct 27, 2006 at 09:04:51AM -0300, Otavio Salvador wrote: Steve Langasek [EMAIL PROTECTED] writes: Unusable or mostly so does not mean unusable in select, minority configurations explicitly enabled by the user. dash as /bin/sh is a corner case, not the common case; which means such bugs do not in fact meet the definition of grave. Well... I didn't know that sererity of bugs depend of how many users can be affected. Using thise criterea you might them reduce the severity of GRUB and Parted RC bugs since them won't affect too much users. That's crap, and you know it. First, having dash as /bin/sh is not so much of a problem as you seem to imply -- I've been running my system that way for ages, and can only remember two cases in which it caused any problems. Second, unusable or mostly so should be read as almost all users who install this package will encounter the bug. If you configure your system to do something valid which triggers the bug (but that configuration is not very common), then almost all users who install the package will *not* encounter the bug, so it's not grave (but still important). -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First draft of review of policy must usage
On Thu, Oct 26, 2006 at 10:18:00AM -0300, Otavio Salvador wrote: Really? Have you read the message where Luk said that #!/bin/sh bugs using no POSIX features isn't RC? That just make me think one thing: Let's release fast, whatever this means! No, it means Let's release at _some_ point, rather than waiting for five years. It's not as if we haven't been taking this type of shortcuts for woody and sarge either. Look, I can understand you're not happy about dunc-tank, but let's not start bringing in ridiculous arguments relating to it in every random discussion, shall we? -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First draft of review of policy must usage
On Thu, Oct 26, 2006 at 12:10:44PM -0300, Otavio Salvador wrote: Wouter Verhelst [EMAIL PROTECTED] writes: No, it means Let's release at _some_ point, rather than waiting for five years. It's not as if we haven't been taking this type of shortcuts for woody and sarge either. I disagree with you. See bellow: This is not about agreeing or disagreeing. It is a fact that policy was not authoritative for what defines an RC bug since well before the woody release. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#367697: clarify 12.3 Additional documentation
On Wed, Aug 16, 2006 at 11:32:01AM -0400, Carl Fink wrote: Really? See, I'd automatically use mc, which also handles compression just fine but doesn't require Apache (and isn't as slow and bloated as Firefox). That's also an option, but not all HTML files look great in lynx -dump output. And like I said, the apache is there since I need it for other things anyway, not just because of the doc stuff. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367697: clarify 12.3 Additional documentation
On Tue, Aug 15, 2006 at 08:56:41PM +0200, Peter Eisentraut wrote: The underlying question here was really, Should PDF documentation be installed compressed? (Or PostScript or OpenOffice etc. in place of PDF.) The policy is not worded precisely enough on that subject. Obviously, you don't want to install HTML compressed. Actually, I do. I run apache on my laptop anyway, since I need it for other things. Doing 'firefox http://localhost/doc/' instead of trying to read files in /usr/share/doc directly makes for a transparent way of not having to deal with the .gz stuff; and the reduced space usage because of the .html files being compressed is nice. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
make -j in Debian packages
Hi, It has come to my attention that the gem package is currently built using 'make -j 4', to have four compiler processes running at the same time. This is a bit troublesome for the poor m68k buildd, which is now suffering under High Load And Constant Swapping (HLACS). I was going to file a flaming bug of severity 'serious', quoting the relevant paragraph from Policy which forbids such behaviour, except it's not there. Well, at least I can't find it... So, my question is whether people think this sort of behaviour for a package's debian/rules file is acceptable. Since most packages currently do not do this, some of our infrastructure (in casu, buildd machines) assume this is not being done. Doing it anyway then might upset those machines -- not just on m68k; when there was talk of a 6-way SPARC buildd machine being set up, I understand that the plan there was to run multiple instances of the buildd software on that machine, rather than having parallel builds run[1]. Having five or six build processes all do 'make -j 4' might grind even the most powerful of machines to a halt. OTOH, I understand that maintainers with machines containing two dual-core processors would prefer compiling their 300M worth of C++ files with the use of more than one of their processors. So there's a bit of a dilemma here. Personally, I understand the issue. In fact, in my upcoming version of belpic, I have some code in debian/rules which checks whether the hostname of the machine happens to be 'rock.grep.be' and if so, compiles the build with '-j3', since rock is in fact an SMP system. However, this type of approach is a bit brute-force, and not at all elegant. In light of that, I'm thinking that it might be interesting if a rules file were to check for the presence of a variable called DEB_PARALLEL_MAX or so and, if set, use that as the value to the '-j' option to make, but that it not specify any -j option (or similar) if the variable is not set. Thoughts? [1] I don't know whether it was eventually set up, and if so, indeed in this fashion, but this is besides the point. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 signature.asc Description: Digital signature
Re: make -j in Debian packages
On Sun, Jun 25, 2006 at 06:11:24PM +0300, Lars Wirzenius wrote: su, 2006-06-25 kello 16:36 +0200, Wouter Verhelst kirjoitti: It has come to my attention that the gem package is currently built using 'make -j 4', to have four compiler processes running at the same time. This is a bit troublesome for the poor m68k buildd, which is now suffering under High Load And Constant Swapping (HLACS). [...] I doubt we need a policy change for this. At some point, we need to stop legislating and start assuming the package maintainers have common sense. It's not a question of legislating; it's more a question of picking a good option and writing the specification in policy. I would actually like to be able to specify 'make -jX' instead of just 'make' in a build. Currently, that's not possible. The absence of common sense in this particular example is what sparked this suggestion, it is not what I'm trying to avoid in the future (though that is, of course, an interesting byproduct -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
On Wed, Jun 21, 2006 at 02:08:57PM +0200, Goswin von Brederlow wrote: Policy says Build-Depends-Indep must be installed for the build target, which sbuild calls. But sbuild does not install Build-Depends-Indep. Same goes for dpkg-checkbuildep -B, it does not test for Build-Depends-Indep while build will always be called. At a minimum policy has to reflect that anything already needed for the build target is in Build-Depends while only the actual *-indep targets and binary require Build-Depends-Indep. Right. I didn't look at it that way. However, since all this was invented and written precisely to accomodate sbuild, it would be madness to suddenly change everything because it seems more aesthetic (or so), and then require that sbuil jump through hoops to accomodate the aestethic feelings of one particular developer. That would be the world upside-down. The idea is to improve sbuild, dpkg-buildpackage, debuild, pbuilder, cowbuilder, lvmbuilder, with a simple change. I would hardly call adding an (two) extra build relationship field jumping through hoops. For clarity, with the above I didn't mean that this change involves jumping through hoops -- only that a hypothetical change which is done only to accomodate someone's aestethical feelings would be. I didn't really oppose this particular change (though I didn't see a good reason to do it -- now I do :-) Sorry I didn't make that any clearer. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
On Tue, Jun 20, 2006 at 07:52:01PM -0700, Thomas Bushnell BSG wrote: Stephen Gran [EMAIL PROTECTED] writes: This one time, at band camp, Thomas Bushnell BSG said: Wouter Verhelst [EMAIL PROTECTED] writes: Sbuild explicitely, by design, only looks at build-depends. So in order for build-depends to be useful at this time if you want a package to build, you need to list mostly everything in build-depends right now anyway. Isn't it sbuild's job to comply with policy, not the other way round? Isn't it policy's job to reflect best current practice, not dictate it? Whenever this has been asked in the past, sbuild has simply declared this is how I want to do it. I have no idea why. The only reason why we need sbuild in the first place is that we want to build architecture-dependent packages on all architectures, not just the one the original developer uploaded a package for. For that, we need to install build-dependencies. We don't explicitely need all build-dependencies; we don't care about those that don't get used in a dpkg-buildpackage -B run, but we do need all those that do. Thus, there is a need for a split between build-dependencies that are needed to build architecture-dependent packages, and build-dependencies that are needed to build architecture-independent packages. Policy currently tries to explain that without explicitly mentioning the above call. I think it does so properly, but that may not be the case--and I'm not a native English speaker, so that may be playing with me a bit, too. However, since all this was invented and written precisely to accomodate sbuild, it would be madness to suddenly change everything because it seems more aesthetic (or so), and then require that sbuil jump through hoops to accomodate the aestethic feelings of one particular developer. That would be the world upside-down. If there is no technical reason for sbuild to behave this way, and if it does not in fact conform to policy, how about making it do the right thing? It does do the right thing. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 signature.asc Description: Digital signature
Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
On Tue, Jun 20, 2006 at 10:50:46AM -0700, Thomas Bushnell BSG wrote: Wouter Verhelst [EMAIL PROTECTED] writes: Sbuild explicitely, by design, only looks at build-depends. So in order for build-depends to be useful at this time if you want a package to build, you need to list mostly everything in build-depends right now anyway. Isn't it sbuild's job to comply with policy, not the other way round? No. Policy is not a stick to beat people with. Our Policy document is not flawless, and errors have been known to occur in Policy before. While an inconsistency between Policy and an individual package is usually a bug in the package rather than a bug in Policy, the same is not true for highly influential implementations of whatever Policy happens to say; e.g., if the definition of the dpkg file format in policy differs from the actual implementation in dpkg, then we usually consider Policy to be either outdated or buggy, since in that particular case, stuff was written for Policy to document existing practice to people not familiar with the dpkg innards. The same is true for buildd/sbuild and build-dependencies; since build-dependencies were defined in Debian to make autobuilding possible, it would be madness to require that buildd and sbuild jump through every hoop that a high enough number of developers (i.e., 5) can come up with and get through the policy process. Therefore, if the implementation of sbuild differs from whatever Policy happens to claim, then Policy is simply wrong. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 signature.asc Description: Digital signature
Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
On Mon, Jun 19, 2006 at 01:02:42PM -0500, Manoj Srivastava wrote: On 16 Jun 2006, Goswin Brederlow stated: The existance of either of the two makes build-arch mandatory. The old fields change their meaning: Build-Depends, Build-Conflicts The Build-Depends and Build-Conflicts fields must be satisfied when any target is invoked. Does the converse hold as well? Is Build-Depends a superset of all dependencies until further notice? If not, if I am using an older dpkg-checkbuildeps or an older sbuild, my package may fail to build. Sbuild explicitely, by design, only looks at build-depends. So in order for build-depends to be useful at this time if you want a package to build, you need to list mostly everything in build-depends right now anyway. It is in fact not against policy to list build dependencies that could technically be put in build-depends-indep in build-depends only, and I believe (though I'm not sure, and can't remember offhand where) that I have already seen some packages do so in the past. So, yes, for all practical matters build-depends right now is a superset of build-depends-indep. Build-Depends-Indep, Build-Conflicts-Indep The Build-Depends-Indep and Build-Conflicts-Indep fields must be satisfied when any of the following targets is invoked: build-indep, binary-indep. The existance of either of the two makes build-indep mandatory. The use of Build-Depends/Conflicts-Arch/Indep is optional but should be used in architecture all/any mixed packages. If any of them is omitted the respective Build-Depends/Conflicts field must be suffient already. ### End of Proposal ### - Simple to implement. + Trivial change in dpkg for the new field. + dpkg-checkbuilddeps has to parse 3 fields (2 with -B option) instead of 2 (1). + sbuild, same change + Simple change for 'apt-get build-dep' Does this mean a package which conforms to the new proposal would fail if the an old sbuild/dpkg-checkbuilddeps is used? In other words, can someone running Sarge build a package from Etch? old sbuild should not be an issue. Official buildd hosts never run sbuild from stable, they run sbuild from a separate repository at db.debian.org. If policy is updated to do something new which will benefit the buildd hosts, then sbuild will follow suit (provided there is code to do that) Of course, if a package does not build with old dpkg-buildpackage, that might be a problem; not sure about that. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#218893: Kicking this back to life
Hi,
The last post to this bug was done on 2004-08-23, which is ages ago. I
think it's safe to say that Bill's proposal (create
debian/rules.{version,targets} files which define what interfaces are
implemented by the debian/rules file) did not get enough seconds.
Personally, I happen to think that such a file would not be a very clean
solution, which is the main reason why I didn't second it; Scott James
Remnant, then the dpkg maintainer (dunno whether he still is), also
hinted something to the same effect.
So, instead, I'm going to propose a patch to which I already hinted in
[EMAIL PROTECTED]: make build-arch and build-indep
mandatory (in the long term), but make it legal for them to depend on
the build target if splitting out their functionality is infeasible or
impossible.
I'm looking for seconds.
Patch follows:
--- policy.sgml.orig2006-05-23 21:52:54.0 +0200
+++ policy.sgml 2006-05-23 22:16:29.0 +0200
@@ -1802,14 +1802,15 @@
/p
p
- If one or both of the targets ttbuild-arch/tt and
- ttbuild-indep/tt are not provided, then invoking
- filedebian/rules/file with one of the not-provided
- targets as arguments should produce a exit status code
- of 2. Usually this is provided automatically by make
- if the target is missing.
- /p
-
+If it is not technically possible or feasible to provide a
+ttbuild-arch/tt or ttbuild-indep/tt target which
+compiles emonly/em that which is specified above, then
+you may make these two targets functionally the same as the
+ttbuild/tt target, for example by declaring the
+ttbuild/tt target a as a make dependency of both the
+ttbuild-arch/tt and the ttbuild-indep/tt targets.
+ /p
+
p
The ttbuild-arch/tt and ttbuild-indep/tt targets
must not do anything that might require root privilege.
--
Fun will now commence
-- Seven Of Nine, Ashes to Ashes, stardate 53679.4
signature.asc
Description: Digital signature
Bug#218893: Kicking this back to life
On Tue, May 23, 2006 at 11:15:14PM +0200, Bill Allombert wrote:
Hello Wouter,
First thank for bringing back this issue, however...
On Tue, May 23, 2006 at 10:17:01PM +0200, Wouter Verhelst wrote:
The last post to this bug was done on 2004-08-23, which is ages ago. I
think it's safe to say that Bill's proposal (create
debian/rules.{version,targets} files which define what interfaces are
implemented by the debian/rules file) did not get enough seconds.
...for the record: the debian/rules.{version,targets} was not the final
proposal. The final proposal was the addition of 'Build-Options' to
debian/control and this proposal was drafted after input from all the
people involved.
Oh? Must've missed that, then.
This proposal is merely waiting for the dpkg
maintainers to make a decision on bug #229357 rather than shelved. Some
developers mentionned their willingness to second it.
As for your proposal: at the time of the discussion, the dpkg maintainer
made it clear it was not an option.
I disagree (I went through the bug's log before providing the patch); He
made clear that the debian/rules.* stuff was not an option in his eyes,
but I didn't see him mention that making build-{arch,indep} would not be
what he wanted to happen.
Of course, I didn't read every letter of every mail, so I could've
missed it.
Since there are new dpkg maintainers, I asked them on Thu, 19 Jan 2006,
what was their opinion on the matter and whether they would accept my
proposal or yours. So far I did not get any answer.
I consider such answer to be a precondition to any useful subsequent
discussion on this topic.
Fair enough.
I proposed this patch because I had not seen any action and therefore
assumed nothing was happening anymore. If that's wrong, so much the
better.
[...]
--
Fun will now commence
-- Seven Of Nine, Ashes to Ashes, stardate 53679.4
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Policy 3.7.0 - /usr/lib/cgi-{bin|lib}
On Wed, May 03, 2006 at 03:02:49PM +0200, Alexis Sukrieh wrote: I plan to do the following for the bugzilla package: 1/ Add a debconf note for notyfing the user about the location change. Eh, no. Please don't. Debconf notes about things that were done to follow policy are the worst cases of debconf abuse, ever. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Make use of invoke-rc.d, if available, mandatory?
On Sun, Apr 02, 2006 at 07:34:52PM -0400, Joey Hess wrote: Lars Wirzenius wrote: Current policy states in section 9.3.3.2 (Running initscripts) the following: The use of invoke-rc.d to invoke the /etc/init.d/* initscripts is strongly recommended[51], instead of calling them directly. Footnote 51 further says: In the future, the use of invoke-rc.d to invoke initscripts shall be made mandatory. Maintainers are advised to switch to invoke-rc.d as soon as possible. I propose that the future has arrived. Seconded. AOL, even if my name appears in your list ;-) (although it's fixed now, since nbd 1:2.7.4-1) -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 signature.asc Description: Digital signature
Bug#148194: debian-policy: Clarification needed regarding multi-line fields
On Wed, Mar 29, 2006 at 03:39:27AM +0300, Guillem Jover wrote: [...] Proposal I'd like «Section 5.2. Source package control files -- `debian/control'» to specify clearly[0] that the following fields contain logical lines: Build-Depends, Build-Depends-Indep, Build-Conflicts, Build-Conflicts-Indep, Pre-Depends, Depends, Recommends, Suggests, Conflicts, Replaces, Provides, Enhances, Uploaders Those fields will be unwrapped by newer dpkg scripts when generating the .deb, .dsc and .changes files, so the few tools that may not support logical lines will be able to cope just fine. I've started doing this for some time now with almost all of my packages, partially breaking policy (I say partially due to dpkg unwrapping the lines, and also due to the current ambiguous situation), Does the current stable dpkg also support this format already? -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Autobuilding and the build-arch target, again
On Mon, Jan 23, 2006 at 11:21:55PM +0100, Bill Allombert wrote: On Mon, Jan 23, 2006 at 11:08:00PM +0100, Wouter Verhelst wrote: And I would strongly suggest you to consider Simon Richter's proposal, which sounds a lot cleaner to me: if you have build-depends-indep in your debian/control file, you must also implement build-arch and/or build-indep. Additionally, that has the advantage that most packages probably already implement it that way. There used to be the issue that the dpkg maintainers were strongly opposed to that, because that break backward compatibility. Yes, but only if packages who declare build-depends-indep without having build-arch exist. Anyone feel like finding that out? ;-) -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Autobuilding and the build-arch target, again
On Mon, Jan 23, 2006 at 02:17:36PM -0600, Bill Allombert wrote: On Mon, Jan 23, 2006 at 07:45:10PM +0100, Michael Banck wrote: The difference between the two is that -q checks whether a target is uptodate and return an appropriate exit code, while -p prints out the data base (i.e. the rules and variables) that results from reading the Makefile. The latter seems more robust to me, so we should reevaluate the It is *not* possible *at all* to detect available targets in a rules file. assertion, IMHO. I would strongly suggest you to consider the Build-Options: build-arch solution I proposed that is going to be much more robust than any parsing of debian/rules. And I would strongly suggest you to consider Simon Richter's proposal, which sounds a lot cleaner to me: if you have build-depends-indep in your debian/control file, you must also implement build-arch and/or build-indep. Additionally, that has the advantage that most packages probably already implement it that way. -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
