El 15/4/24 a las 22:26, Bill Allombert escribió:
On Tue, Jan 30, 2024 at 09:52:39AM +, MOESSBAUER, Felix wrote:
On Fri, 04 Aug 2023 10:44:38 + sohe4b+2fz7rb0ixc53g@cs.email wrote:
Package: base-files
Version: 12.4+deb12u1
Followup-For: Bug #1039979
Control: tags -1 patch
I attach a
reassign 1039979 debian-policy
thanks
Dear Policy editors:
In this bug I'm asked to make /var/run and /var/lock symlinks
to be relative.
Maybe it's the right thing to do, but last time I tried to do that,
this is what happened:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690345
[
El 17/9/23 a las 0:12, Daniel Gröber escribió:
Sam, Russ, Bill,
Thanks for your input. To be quite frank I still don't see how the
interpretation of allowing configuration files outside of /etc can be
supported based on the policy text.
Hello. I apologize for not having read the discussion in
I wrote:
I believe that by choosing the wording appropriately, we can still keep this
desired property of Policy while still not mandating any given implementation.
Sorry, that was terribly worded. I meant that we can avoid the hassle of
documenting everything dh_installsystemd does and at the
El 10/9/23 a las 4:09, Russ Allbery escribió:
I therefore would like to propose a first: I think Policy should simply
say that any package that provides a system service should use debhelper
and rely on dh_installsystemd to put the appropriate commands in its
maintainer scripts. (We can then
El 28/1/23 a las 14:07, Ansgar escribió:
+---
| The required packages are called build-essential, and include packages
| with Priority "required" and additional packages. An informational
| list of additional packages can be found in
| /usr/share/doc/build-essential/list (which is contained in
El 4/1/23 a las 17:45, Julien Cristau escribió:
Like I said in the debootstrap bug, I believe we should treat a case
where a package is Priority: required but not actually required by the
Essential set as a bug in package priorities, and neither debootstrap
nor policy need to change.
I take
El 4/1/23 a las 19:28, Sam Hartman escribió:
"Santiago" == Santiago Vila writes:
Santiago> I think you can't really estimate such thing. You seem to
Santiago> imply that we have been allowing packages with missing
Santiago> build-dependencies for a lo
El 4/1/23 a las 19:54, Bill Allombert escribió:
BTW: Today I reported that kodi did not build without tzdata. But in the end
this was not a missing build-dependency of kodi, but a missing *binary*
dependency
of one of the build-dependencies of kodi.
So is there a service that detect such
El 4/1/23 a las 18:23, Sam Hartman escribió:
I think that the
cost of going and adding all the build-depends on
required-but-not-build-essential is not worth what I estimate we'd gain
from having this extra information.
I think you can't really estimate such thing. You seem to imply that we
El 4/1/23 a las 17:16, Russ Allbery escribió:
But if you are building new Debian packages,
by definition you are not in a tiny minimal system case. build-essential
is already somewhat arbitrary and chosen for convenience (most packages do
not require a C++ compiler). Why not expand
El 4/1/23 a las 2:32, Sam Hartman escribió:
"Santiago" == Santiago Vila writes:
Santiago> As an example, packages tzdata, mount or e2fsprogs are not
Santiago> build-essential and afaik have not been for a long time,
Santiago> but there are still
Package: debian-policy
Version: 4.6.2.0
Severity: wishlist
Hello. This is an attempt to put the basis for fixing this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837060
As an example, packages tzdata, mount or e2fsprogs are not build-essential
and afaik have not been for a long
El 18/12/22 a las 15:34, Chris Hofstaedtler escribió:
Package: mawk
Version: 1.3.4.20200120-3.1
Priority: required
base-files Pre-Depends awk, mawk Provides awk
Could become Priority: optional?
I can answer for that one. A long time ago, we decided to ensure
that some implementation of awk
reassign 1009343 debian-policy
thanks
El 12/4/22 a las 5:41, Daniel Kahn Gillmor escribió:
Package: base-files
Severity: wishlist
Version: 12.2
Expat and Boost-1.0 are both fairly common licenses in debian. I
believe they are both well-defined, stable, and reasonably
well-understood variants
reassign 1013195 debian-policy
thanks
El 18/6/22 a las 23:45, Salvo 'LtWorf' Tomaselli escribió:
Package: base-files
Version: 12.2
Severity: normal
X-Debbugs-Cc: tipos...@tiscali.it
Dear Maintainer,
AGPL-3 license is not present in the base files.
This forces me to include verbatim the very
reassign 924094 debian-policy
thanks
El 9/3/19 a las 15:13, Steffen Moeller escribió:
Package: base-files
Version: 10.1
Severity: normal
Dear Maintainer,
* What led up to the situation?
I was packaging a tool with that license without shipping it.
* What outcome did you expect
On Fri, Mar 15, 2019 at 04:51:11PM +0100, Helmut Grohne wrote:
> Since dpkg will not prevent upgrading of other packages while an
> ``essential`` package is in an unconfigured state, all ``essential``
> packages must supply all of their core functionality even when
> -unconfigured. If the
On Fri, Mar 15, 2019 at 04:51:11PM +0100, Helmut Grohne wrote:
> Since dpkg will not prevent upgrading of other packages while an
> ``essential`` package is in an unconfigured state, all ``essential``
> packages must supply all of their core functionality even when
> -unconfigured. If the
> > In a practical level, because you already see what happens when
> > you configure any package which uses users defined in /etc/passwd
> > without a minimal /etc/passwd in place. Again in a practical level,
> > once we know it, we can't pretend that we don't know it.
>
> That's what the
On Thu, Mar 14, 2019 at 10:37:46AM +, Simon McVittie wrote:
> On Thu, 14 Mar 2019 at 10:21:30 +0100, Santiago Vila wrote:
> > The reason I'm often asked to add hacks to base-files.postinst is only
> > that base-files is usually configured in the second place
>
> I think
On Thu, Mar 14, 2019 at 07:50:27AM +0100, Johannes Schauer wrote:
> I agree that we should not expect maintainers to write numeric user and group
> ids into their maintainer scripts. This is not only hard to write but also
> hard
> to read and maintain. In my opinion, using numeric ids should
On Wed, Mar 13, 2019 at 01:15:02PM +0100, Johannes Schauer wrote:
> I'm not advocating for doing "hacks here and there so that bootstrapping tools
> work properly" as you put it but that we think about the question of whether
> maybe there is a better way to populate an empty directory with
On Tue, Mar 12, 2019 at 07:30:21PM +0100, Helmut Grohne wrote:
> > Do any of them still don't know that base-passwd should be configured
> > first because otherwise any other package using root (be it base-files
> > or any other) will fail? I think this was already settled in the last
> >
On Tue, Mar 12, 2019 at 04:17:10PM +0100, Helmut Grohne wrote:
> Package: base-passwd,base-files,debian-policy
>
> Debian policy section 3.8 says:
>
> | Essential is defined as the minimal set of functionality that must be
> | available and usable on the system at all times, even when packages
>
On Tue, Mar 12, 2019 at 04:17:10PM +0100, Helmut Grohne wrote:
> Package: base-passwd,base-files,debian-policy
>
> Debian policy section 3.8 says:
>
> | Essential is defined as the minimal set of functionality that must be
> | available and usable on the system at all times, even when packages
>
On Thu, Nov 08, 2018 at 02:51:55PM +, Ian Jackson wrote:
> [...]
Looks ok at first read, maybe a little bit too much normative.
One minor comment:
> (i) a failure of the build, in which case the additional packages
> MUST be declared in Build-Conflicts);
As we talked before, that's
On Sat, Nov 03, 2018 at 03:42:20PM -0700, Russ Allbery wrote:
> In a way, I don't think this goes far enough. Build-Conflicting with
> something installed by debhelper would be incredibly painful and would
> basically require the package be built in a chroot.
I'm not sure what do you mean by
> > While we are at it, I understand, because it would involve a huge
> > amount of computation to determine, that we can't test every package
> > against every other binary package to discover undeclared
> > build-conflicts.
>
> Well, indeed. In fact, this is the reason why I don't see how we
reassign 910548 debian-policy
thanks
On Sun, 7 Oct 2018, Paul Hardy wrote:
> Package: base-files
> Severity: wishlist
> Tags: patch
>
> Hello,
>
> I recently formatted the Unicode Data license for the d/copyright file
> of a Debian package that I created. I thought I would offer it to
>
This would be a "pseudo-patch":
Replace this:
The "/usr/local" directory itself and all the subdirectories created
by the package should (by default) have permissions 2775 (group-
writable and set-group-id) and be owned by "root:staff".
by this:
The "/usr/local" directory itself and all the
reassign 882628 debian-policy
thanks
Dear Nicolas: The file /usr/share/doc/base-files/FAQ contains
the rationale for this reassign. Please read it.
Thanks.
On Sun, Aug 06, 2017 at 08:03:23AM -0700, Sean Whitton wrote:
> control: retitle -1 Transitioning perms of /usr/local
>
> Hello Santiago,
>
> The TC decision in #484841 is not yet reflected in Policy.
>
> We could close the bug by simply dropping the requirement that
> /usr/local be
On Fri, Aug 04, 2017 at 03:42:34PM -0400, Sean Whitton wrote:
> On Thu, Aug 03, 2017 at 03:43:56PM +, Mike Gabriel wrote:
> > I am not saying that the build target must not be empty. I can be empty but
> > the build-a ... build-n dependecies have to be moved away from the binary
> > target and
On Wed, Aug 02, 2017 at 10:52:59AM -0400, Sean Whitton wrote:
> control: tag -1 -patch
>
> Hello again Santiago,
>
> Some of us here at DebCamp have been reading your message and we're
> still not sure of your intention.
>
> On Thu, Aug 25, 2016 at 09:41:26PM +0
Package: debian-policy
Version: 3.9.8
Severity: wishlist
Greetings.
Debian Policy 4.9 says:
Both binary-* targets should depend on the build target, or on the
appropriate build-arch or build-indep target, if provided, so that the
package is built if it has not been already.
I don't see the
Package: debian-policy
Version: 3.9.8
Greetings.
Debian Policy 4.9 says:
For some packages, notably ones where the same source tree is compiled
in different ways to produce two binary packages, the build target
does not make much sense. For these packages it is good enough to
provide two
Package: debian-policy
Severity: wishlist
Hello.
Policy 7.7 says: (Bold in "can" is mine)
Source packages that require certain binary packages to be installed
or absent at the time of building the package *can* declare
relationships to those binary packages.
I interpret this "can" in the
On Wed, Aug 26, 2015 at 11:14:48PM +0200, Thorsten Alteholz wrote:
On Tue, 25 Aug 2015, Santiago Vila wrote:
Not having a debian/copyright file in the source package does not
affect usability of the package in *any* way.
If it is not possible to add the copyright and license information
On Sun, 23 Aug 2015, Thorsten Alteholz wrote:
But policy says that there should be such a copyright file. Violating such a
clause is at least an important bug.
I guess you refer to policy when it says that we could match must
with serious and should with important.
However, the BTS
On Thu, 20 Aug 2015, Charles Plessy wrote:
Dear Santiago and everybody,
how about the following ? (in section 4.5)
[...]
Yes, please. Seconded. Would be nice to add some sort of rationale
to policy.
2. Why would policy say should instead of must, if we then do not
allow for exceptions? (packages generating copyright file at build time).
This is not my area, but why should there be an exception?
To allow for the file to be automatically generated at build time,
which in turn avoids
[ Dropping CC for Simon and Russ because I know for sure they are in
-policy ].
On Sun, Aug 16, 2015 at 06:23:52PM +0200, Thorsten Alteholz wrote:
But what shall be the source for this generation?
I was basically doing cat debian/copyright.in LICENSE
Not anything AI-style, and not trying to
Hello.
I received two bugs about a missing debian/copyright in source package
(the copyright file is generated at build time).
Questions:
1. This seems a mass-bug filing, which last time I checked it is
something that should not be done before asking in -devel. Did I
miss the announcement about
On Fri, Jun 26, 2015 at 04:40:58AM +0200, Guillem Jover wrote:
So given that the timezone name has never been accepted, many
time-parsing functions ignore it, it is redundant, declared obsolete
by RFC5322 and Debian policy dropped an explicit reference to it due
to bug 569174. I'd say we
+ If your package includes the scripts prgnconfig.sub/prgn and
+ prgnconfig.guess/prgn, you should arrange for the versions
+ provided by the package packageautotools-dev/package be used
+ instead (see packageautotools-dev/package documentation for
+
Package: developers-reference
Version: 3.4.14
Tags: patch
The way I read the IRC logs in Bug#685646, suffixes like +deb8u1
are the preferred version numbering scheme for any upload to stable,
regardless of them being Non Maintainer Uploads or Maintainer Uploads.
The current text says NMU which
Package: developers-reference
Version: 3.4.14
Tags: patch
While we are at it, Debian 7 is preferred over Debian 7.0 if we refer
to wheezy during all its lifetime, including all the point releases.
Patch follows (to be applied after the previous one).
diff --git
On Mon, Nov 17, 2014 at 10:48:15PM +0900, Charles Plessy wrote:
One of the potential uses of the Extra priority was to allow for
co-installing all packages down to the Optional priority. However,
this goal is not seem realistic anymore given the current size of
the Debian archive, and indeed,
Hmm. We drop things when we clearly see they have no purpose, or we
see they are harmful.
For example, some people claim that the rule about priorities and
dependencies is actively harmful, and I think they have a point indeed.
In this case, however, I fail to see the rationale for actually
On Sat, Nov 15, 2014 at 04:31:37PM +, Simon McVittie wrote:
For the reasons Matthias and I have outlined, I think the current rules
are both unnecessary and harmful. Automating an unnecessary and harmful
thing does not make it any more necessary, or less harmful.
My proposal would be to
On Sat, Nov 15, 2014 at 09:09:06AM +0100, Matthias Urlichs wrote:
If I read #759260 correctly, Gerrit Pape p...@dbnbgs.smarden.org objected
to allowing depending on lower-priority packages and said that the current
file a bug and raise the priority process is just fine. However, IMHO it
On Wed, Oct 29, 2014 at 07:30:57PM +0100, Matthias Urlichs wrote:
That's obvious. What is not so obvious, to me, is why we would still
want the current policy in the first place, given that everything(?)
is resolved via dependencies these days.
Maybe because current policy allows one to take
On Thu, Oct 23, 2014 at 01:37:11PM +0100, Simon McVittie wrote:
I agree with your analysis, although perhaps not the wording. Maybe
something like:
# The priority of a package should be based on the functionality
# of the package itself, and not on whether high-priority packages
# depend on
On Thu, Oct 23, 2014 at 03:04:43AM +0200, Adam Borowski wrote:
can't even be detected via automated means.
Why not?
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
On Wed, Oct 29, 2014 at 01:30:55PM +, Simon McVittie wrote:
On 29/10/14 12:41, Santiago Vila wrote:
If we are going to take that route, we might just make all libraries
optional as a general rule.
That seems reasonable to me, with the possible exception of the few
libraries that could
On Wed, Oct 15, 2014 at 11:20:21AM +0100, Simon McVittie wrote:
On 15/10/14 00:17, Santiago Vila wrote:
Do we need a paragraph in policy saying explicitly you should not use
profile.d?
For some packages, like bash-completion and
packagekit-command-not-found, the whole point of the binary
Hello.
For a lot of time, I was reluctant to modify /etc/profile to support
/etc/profile.d because my understanding of policy, namely this:
A program must not depend on environment variables to get
reasonable defaults. (That's because these environment
variables would
Hi.
If the only thing we need here is a transition plan, here we go:
I propose the following plan to change the *default* behaviour of
group staff and /usr/local at the same time we completely keep
backwards compatibility with already installed systems.
First we modify base-files to do this:
*
reassign 621462 debian-policy
thanks
On Thu, 7 Apr 2011, onlyjob wrote:
Package: base-files
Version: 6.0squeeze1
Severity: wishlist
Tags: patch
AGPL-3 missing from /usr/share/common-licenses
The debian policy group decides about this, not me (please read
base-files FAQ). Reassigning.
reassign 608324 debian-policy
thanks
On Wed, 29 Dec 2010, Ana Guerrero wrote:
Package: base-files
Version: 6.0
Severity: wishlist
Hi,
I have seen you did recently an update of the licenses from
http://ftp.gnu.org/gnu/Licenses/ but you did not include the Affero
license
On Tue, 29 Jun 2010, Russ Allbery wrote:
Russ Allbery r...@debian.org writes:
I therefore propose adding GPL version 1 to the list of licenses said by
Policy to be in common-licenses and asking Santiago to include a copy in
base-files. I'm not including a diff since it would just create
On Sat, 12 Jun 2010, Russ Allbery wrote:
Russ Allbery r...@debian.org writes:
2. Apply the patch to Policy included below, which removes this license
from the list of licenses we tell people to reference from
/usr/share/common-licenses and explains why.
This patch has now been
On Thu, 10 Jun 2010, Russ Allbery wrote:
Given that, while I'm very sympathetic to Santiago's argument, I also
think that we should be able to represent in packages their upstream
licensing statement and not be implicitly relicensing them under later
versions of the GPL, and without including
Package: debian-policy
Version: 3.8.4.0
Severity: wishlist
On Thu, 20 May 2010, Roger Leigh wrote:
On 20/05/2010 20:43, Steve Langasek wrote:
I don't think it's practical to ever get rid of the legacy UID range
fragmentation in the 16-bit space. Better would be to plan a transition to
Hmm, I see this is already reported as Bug#161912.
However, this report includes a patch :-)
Feel free to merge them anyway.
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
On Wed, 10 Feb 2010, Luca Falavigna wrote:
Package: developers-reference
Version: 3.4.3
Severity: wishlist
Tags: patch
We have several meta-packages and transitional packages in the archive, some
of them do not document that anywhere in their description.
Users should be given such an
reassign 565884 debian-policy
thanks
On Tue, 19 Jan 2010, Thibaut Paumard wrote:
Package: base-files
Version: 5.0.0
Severity: wishlist
Hi,
there is a growing body of packages (or at least files) under [1]CeCILL
license in the archive. The CeCILL licenses are wordy and the project
reassign 541703 debian-policy
thanks
In this bug, I'm asked to include the FreeBSD license (which is not
exactly the same as the BSD license) into common-licenses.
As usual, I delegate this decision to the policy group (hence the reassign).
[ IMHO, the proposed license is so small that we don't
On Tue, 11 Aug 2009, Don Armstrong wrote:
On Tue, 11 Aug 2009, Santiago Vila wrote:
Could we please move the default to 755, not 2775, like every other
normal directory in Debian? There is little point in keeping those
directories world-writable if they stop being owned by group staff
Could we please move the default to 755, not 2775, like every other
normal directory in Debian? There is little point in keeping those
directories world-writable if they stop being owned by group staff.
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of
On Fri, 25 Apr 2008, Don Armstrong wrote:
Package: debian-policy
Version: 3.7.3.0
Severity: wishlist
User: [EMAIL PROTECTED]
UserTags: discussion
Tag: patch
The requirement of optional packages not to conflict with eachother
and not to depend on essential packages are outdated, and appear to
On Sun, 16 Mar 2008, Russ Allbery wrote:
Russ Allbery [EMAIL PROTECTED] writes:
I have gotten no further feedback on this proposal. I would like to
resolve this bug for the next Policy release one way or the other.
Could others reading the Policy list please express an opinion on
reassign 458385 debian-policy
thanks
On Sun, 30 Dec 2007, Allison Randal wrote:
Package: base-files
Version: 4.0.1
Severity: wishlist
I'd like to request the addition of the file:
http://www.perlfoundation.org/attachment/legal/artistic-2_0.txt
as Artistic-2 in
reassign 435476 debian-policy
thanks
On Wed, 1 Aug 2007, Carl Fürstenberg wrote:
Package: base-files
Version: 4.0.0
Severity: wishlist
I've seen plenty of instances of the usage of MIT License. Wouldn't it
be optimal to include it as a common license?
Maybe, or maybe not. I prefer to
reassign 436105 debian-policy
thanks
On Sun, 5 Aug 2007, Sam Hocevar wrote:
Package: base-files
Version: 4.0.0
Severity: wishlist
There are still many packages that mention the GPL version 1 in their
copyright file (around 350). Many Perl packages, but also Perl itself
and widespread
On Sat, 28 Jul 2007, Florian Weimer wrote:
* Russ Allbery:
Andreas Barth [EMAIL PROTECTED] writes:
* Florian Weimer ([EMAIL PROTECTED]) [070630 10:16]:
But do we really want to license everything which is GPL version 2 or
later under the GPL version 3?
And how do we discriminate
On Sat, 30 Jun 2007, Florian Weimer wrote:
* Santiago Vila:
+ file. Packages should not refer to GPL and LGPL symlinks in
+ that directory since different, incompatible versions of these
+ licenses have been published by the Free Software Foundation
This proposal does essentialy two things:
- Disambiguate GPL/LGPL versioning requirement by extending it to any DFSG
compatible version the FSF may publish.
- Deprecate use of symlinks, since they're a source of problems (as exposed
by GPLv3, see
+ file. Packages should not refer to GPL and LGPL symlinks in
+ that directory since different, incompatible versions of these
+ licenses have been published by the Free Software Foundation,
+ hence using the symlinks could lead to ambiguity.
I disagree with this.
On Sat, 30 Jun 2007, Robert Millan wrote:
On Sat, Jun 30, 2007 at 12:17:00AM +0200, Santiago Vila wrote:
+ file. Packages should not refer to GPL and LGPL symlinks in
+ that directory since different, incompatible versions of these
+ licenses have been published
FYI: The FSF will release the GNU GPL version 3 this Friday. See:
http://lists.gnu.org/archive/html/info-gnu/2007-06/msg00013.html
Before anybody submits a bug report against base-files: Is there an
official statement from Debian about the DFSG-free status of GPLv3?
I would like to put it in
Package: debian-policy
Version: 3.7.2.2
base-files_4.0.0, just uploaded for unstable, has now the GFDL in
common-licenses (as both GFDL-1.2 and a symlink GFDL - GFDL-1.2).
Therefore, the paragraph in policy saying Note that the GFDL is new
here, and the license file may not yet be in place in
reassign 401173 debian-policy
thanks
Note to the submitter: This bug does not belong to base-files.
Please read base-files FAQ!
On Fri, 1 Dec 2006, Jari Aalto wrote:
Package: base-files
Version: 4
Severity: normal
The list of licenses is limited in:
$ ls -1
reassign 381729 debian-policy
severity 381729 wishlist
thanks
Licenses in /usr/share/common-licenses are added or removed if the
debian-policy group says they should be added or removed, as this is
definitely something I don't want to decide as base-files maintainer.
Please see Why isn't license
On Mon, 30 Jan 2006, cobaco (aka Bart Cornelis) wrote:
On Sunday 29 January 2006 02:36, Santiago Vila wrote:
+Sometimes two or more packgages need to be able to modify
the +same configuration file. One such case is were related
packages +share
+Sometimes two or more packgages need to be able to modify the
+same configuration file. One such case is were related packages
+share a configuration file (e.g. bash and other bourn compatible
+shells share /etc/profile).
You are implicitly saying
On Mon, 24 Jan 2005, Bill Allombert wrote:
On Mon, Jan 24, 2005 at 01:25:44PM +0100, Santiago Vila wrote:
On Mon, 24 Jan 2005, Jeroen van Wolffelaar wrote:
Yes, I understand that, and I mostly agree. Now please write a lintian
warning for PT_GNU_STACK. Mass bug filing me even before
Marc Haber wrote:
Santiago Vila [EMAIL PROTECTED] wrote:
On Mon, 8 Dec 2003, Marc Haber wrote:
Policy 2.5 says that packages must not depend on packages with lower
priority values. From what I tried to research, that rule is meant to
allow CD builders to build Debian foo standard CDs
On Mon, 8 Dec 2003, Marc Haber wrote:
Policy 2.5 says that packages must not depend on packages with lower
priority values. From what I tried to research, that rule is meant to
allow CD builders to build Debian foo standard CDs containing
required, important and standard packages, guaranteed
I object to making the packaging system more complex without a real gain.
We should better document what Build-Depends-Indep: really mean:
That which autobuilders do not need to install to produce Architecture: any
packages via the clean, build and binary-arch targets only.
We could well keep
On Mon, 3 Nov 2003, Adam Heath wrote:
On Mon, 3 Nov 2003, Santiago Vila wrote:
I object to making the packaging system more complex without a real gain.
Well, without adding complexity, I do agree to having a field that specifies
the calling procedure for building the package.
Exactly
On Mon, 3 Nov 2003, Bill Allombert wrote:
On Mon, Nov 03, 2003 at 06:09:46PM +0100, Santiago Vila wrote:
What are the real benefits from having build-arch and build-indep?
Are there really so many packages which would benefit from having them?
(Remember debug in DEB_BUILD_OPTIONS
On Mon, 3 Nov 2003, Andreas Metzler wrote:
On Mon, Nov 03, 2003 at 07:49:05PM +0100, Santiago Vila wrote:
[...] I would like to see the real benefits from
changing the format of debian/rules.
Did you miss the original subject of the thread? The benefit of the
proposal is to make the split
On Tue, 4 Nov 2003, Bill Allombert wrote:
On Mon, Nov 03, 2003 at 11:35:48PM +0100, Santiago Vila wrote:
What about optional fields in the control file with default values:
Build-Arch: build
Build-Indep: build
(and therefore may be omitted), but that can be overridden in this way
Josip Rodin wrote:
Manoj Srivastava wrote:
Pristine sources are already a desired, but not required,
characteristic. There are enough brain dead upstream packaging
practices that we can not mandate pristine sources.
Dont go blaming upstream for debians problems, lots of other
On Mon, 21 Jul 2003, Josip Rodin wrote:
On Fri, Jun 06, 2003 at 01:52:58PM +0100, Colin Watson wrote:
[...]
I propose this patch:
--- policy.sgml~2003-07-21 12:17:53.0 +0200
+++ policy.sgml 2003-07-21 12:31:13.0 +0200
@@ -779,11 +779,24 @@
/p
p
On Mon, 21 Jul 2003, Josip Rodin wrote:
On Mon, Jul 21, 2003 at 01:25:35PM +0200, Santiago Vila wrote:
I second the clarifying paragraph. I object to changing to should.
We must fix the wrong priorities once and forever, and keep them sane
sane from release to release. If the *current
On Mon, 21 Jul 2003, Josip Rodin wrote:
On Mon, Jul 21, 2003 at 01:54:59PM +0200, Santiago Vila wrote:
By unenforceable you mean that ftp.debian.org do not allow NMUs?
No, I mean that a complete consistency in the set of 10K packages is
practically impossible to achieve, let alone sustain
reassign 201883 debian-policy
thanks
On Fri, 18 Jul 2003, Luca - De Whiskey's - De Vitis wrote:
Package: base-files
Version: 3.0.2
Severity: minor
I'd like ZPL (Zope Public License) to be added to the list of common
license in Debian. I think that ZPL is common enough (at least 10
1 - 100 of 430 matches
Mail list logo
