Bug#1039979: base-files: /var/run and /var/lock should not be absolute symlinks

[Santiago Vila]

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 patch to change absolute symlinks to relative symlinks,

which would fix this bugreport if you choose to do so.

At least the /var/run directory is also created as a symlink to ../run
by tmpfiles.d:

/usr/lib/tmpfiles.d/var.conf from the systemd package contains:
L /var/run - - - - ../run


Why not fix /usr/lib/tmpfiles.d/var.conf to create the correct link then ?
/usr/lib/tmpfiles.d/var.conf is not policy-compliant as it is.


Note that you are using here the words "fix" and "correct" to mean "what policy 
says".

However, the point the reporter was trying to make (if I understood correctly)
is that there is already a "trend" by which it's more useful to have those
symlinks as relative, and the systemd reference was just to highlight such 
trend.

So the question would be: Is policy really correct by requesting those
symlinks to be absolute considering that there seems to be a significant amount
of people (including systemd upstream) who consider more useful for them
to be relative?

Thanks.

Re: base-files: /var/run and /var/lock should not be absolute symlinks

[Santiago Vila]

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

[ Summary: I had to revert the change because it was against policy ].

So, I'm reassigning this bug to debian-policy. Please drop me a note whenever
there is a consensus that relative symlinks are ok for /var/run and /var/lock
(even if there is not a new policy release reflecting it yet).

Thanks.

Re: Does iproute2 moving config files to /usr/lib violate section 10.7.2?

[Santiago Vila]

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 full.

I believe there is an underlying semantic problem here.

Those files were shipped in /etc before. They are not shipped
in /etc anymore. Instead, files with identical contents
are now shipped in /usr/lib.

In your eyes, this is enough to consider that the files
have "moved", and maybe that's why you are still calling
them "configuration files outside of /etc".

But this is all about intent. It's not the format of the file
or the way they modify the behaviour of the program what
makes them to be "configuration files". It's the intent.

If the files are intended to be modified "in place" by the
system admin, we call them configuration files (and we try hard
to put them in /etc). If they are not intended to be modified by
the system admin, we don't call them configuration files (and
we try hard not to put them in /etc).


So I maintain that the current policy text doesn't allow configuration
files outside of /etc.


I agree, and this is why I think there is a semantic problem. The way I see it,
the problem is not really that there are "configuration files outside of /etc",
the problem is calling them configuration files when they are not anymore.

The definition of "configuration file" may not be perfect, but we have
to be careful not to twist it too much, because we might find ourselves
in the difficult position that lots of files in /usr/lib would also be
"configuration files outside of /etc".

That's why I believe intent is essential here.

Thanks.

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Santiago Vila]

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 same time not
*formally* mandating the use of dh_installsystemd.

Thanks.

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Santiago Vila]

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 discuss whether we should do the same
for init scripts and dh_installinit, although its stanzas are simpler.)


Hello. I don't like this approach, and I believe we are mixing two different 
things
here. One of them is our ability (or lack thereof) of policy to catch up with
real development done elsewhere. Another one is the fact that policy does
not mandate any given implementation.

I believe that by choosing the wording appropriately, we can still keep this
desired property of Policy while still not mandating any given implementation.

(i.e. we could essentially say "you should do the same thing
as dh_installsystemd does", but in an elegant way).

Thanks.

Bug#1029831: debian-policy: Make required packages build-essential

[Santiago Vila]

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 the
| build-essential package).
+---

This only documents existing practice as practically all systems have
required packages installed.


(I replied in -devel but should have replied here).

What you call current practice is only current debootstrap behaviour.

There are already packages in bullseye having build-depends
on tzdata, and afaik it was not me who reported them to have such
build-dependency. If current practice was really not to consider
tzdata as build-essential, as you say, somebody would have reported
those build-dependencies as a bug, because we don't use build-depends
when the package is build-essential.

I would say, therefore, that current practice all this time has really
been to report those bugs and fix them, i.e. current practice is
that tzdata is not build-essential, despite debootstrap behaviour.

Thanks.

Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential

[Santiago Vila]

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 your word that policy does not need to change and I've just closed
this report, as there is clearly not a consensus that policy needs a 
clarification.

I see that you have just downgraded the debootstrap bug to wishlist.

Have you actually asked ftpmasters to downgrade the priorities
that would have to be downgraded so that debootstrap does not install
packages that are not build-essential when using the buildd profile?

Thanks.

Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential

[Santiago Vila]

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 long time, but that's not
 Santiago> accurate. The *buildds* have been allowing packages with
 Santiago> missing build-dependencies for a long time, but I have
 Santiago> been reporting those bugs for a long time as well.

Thanks for the additional information.
You have not changed my mind.
I would prefer to solve this situation by increasing the build essential
set based on what I know today.


This bug report was a request to clarify policy without altering it, for those
who don't understand "packages required to build a hello world program" which
is already in policy.

But I'm starting to feel uncomfortable with the fact that the bug report is 
actually
being used to propose a policy change, which was never the intent, as it's 
something
completely different.

I fully respect those who want to change policy regarding the build-essential 
definition,
but I find it not appropriate to do that in this report, which was merely 
asking for
a clarification of current policy.

Therefore I withdraw my suggestion that current policy should be clarified by 
closing this bug,
as there seems not to be a consensus that it needs a clarification, and I 
respectfully request
that those willing to change the build-essential definition do so in another 
bug report.

Thanks.

Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential

[Santiago Vila]

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 missing *binary* dependency ?
This seems the missing piece.


No, there is not such a "service" (not sure if understood what do you mean by 
that).

The missing binary dependency was discovered because I am doing archive-wide 
rebuilds
following Policy 4.2, i.e. using a chroot containing only essential and 
build-essential
packages, and because kodi maintainers immediately realized about the root of 
the problem.

Thanks.

Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential

[Santiago Vila]

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 have
been allowing packages with missing build-dependencies for a long time, but 
that's
not accurate. The *buildds* have been allowing packages with missing 
build-dependencies
for a long time, but I have been reporting those bugs for a long time as well.

So it's not as if I were proposing that we start doing something that we have 
never done.
My only aim is that we detect such bugs earlier in the chain, in the buildds, 
where it should be.

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.

Also, several weeks ago, a bunch of ruby packages which did not build from 
source
had a common build-dependency which had a missing dependency on tzdata.

This means that smaller build environments help to detect missing binary
dependencies as well.

Thanks.

Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential

[Santiago Vila]

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 build-essential to what we're
largely doing in practice to fix the consistency problem (which is a real
issue) but not add work tweaking build dependencies for a bunch of
packages?


A minimal build essential set provides and generates useful information that
a build essential set which is not so minimal does not provide.

For example, some packages have unit tests which depend on the information
stored on tzdata. In some cases, changes in tzdata causes those unit tests
to fail.

The tzdata package is updated often in stable. If we were to know in advance
what packages could break, we could look at the packages which build-depend on 
it,
either directly or indirectly.

If we don't have such information, we can't even try to do that.

So, a minimal build essential set has the same benefits as a minimal essential 
set,
namely, that we know a lot better which are the real build-dependencies or the
real dependencies, as they are not hidden.

Thanks.

Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential

[Santiago Vila]

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 people who believe that they are
 Santiago> build-essential for the mere fact that they are
 Santiago> priority:required.

Why not just make all required packages build-essential?
I agree we should fix the class of bugs you are talking about, but it
seems like in some cases it might be easier to fix them by declaring
them not buggy.


Because required to build != required in a _running_ system

The idea of declaring something not a bug to avoid fixing it is not very 
appealing
to me. I believe we can do better than that. The proposal made in bug #837060
(namely, that debootstrap stops installing packages not build essential when
using the buildd profile) is IMO the optimal way to fix the problem at its root,
because once that packages with missing build-depends start failing in the 
buildds,
then it will be clear for everybody that there is a missing build-depends.

(The initial email in such bug by Johannes Schauer describes the problem
very well).

Thanks.

Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential

[Santiago Vila]

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 time, but there are still people who
believe that they are build-essential for the mere fact that they are
priority:required.

Therefore I think a clarification would be useful to clear those kind
of misconceptions.

Proposed text, to be added after the paragraph which defines build essential
based on the Hello World example:

--
From this definition it follows that packages of required priority are not
necessarily build essential, as it is possible for some them not to be
needed at all to compile, link and put in a Debian package a Hello World
program written in C or C++.
--

Next step would be to add a paragraph saying tools like debootstrap when used
to create chroots for building (i.e. "buildd" profile in deboostrap) should try
to keep the list of installed packages as minimal as possible, as far as
doing so does not become disruptive (for example, apt is technically not
build-essential but it is required to install the build-dependencies).

Thanks.

Bug#950440: debian-policy: Confusing conflation of Essential:yes w/ Priority:required

[Santiago Vila]

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 was always present in the system,
making awk to be both "essential" and "virtual". The Pre-Depends
of base-files on awk (being base-files essential itself) is the way
to implement such assurance that there is always some awk installed.

The rationale is that we made perl essential as an available
scripting language (via perl-base), and not doing the same
with "good old awk" as an essential scripting language would be awkward.

The mawk package has priority required so that deboostrap does not have to
"decide" which awk to install in a new system.

btw: I'm not sure if this bug is related or not with the fact that debootstrap
installs all required packages by default. I'd like to make a policy proposal
saying tools like deboostrap should try not to install packages which are
not build-essential. Does anybody remember if there is already a debian-policy
bug for that?

[ For the purpose of achieving sane chroots, we don't need to modify so much 
priorities ].

Thanks.

Re: Bug#1009343: please consider adding Boost-1.0 and Expat to /usr/share/common-licenses

[Santiago Vila]

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 of the MIT family of licenses.

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ even
explicitly recommends that software with an "MIT" license that matches
the Expat terms should instead refer to Expat.

It would seem reasonable to include both of these licenses in
/usr/share/common-licenses/ to discourage adoption of other
less-well-known variants in the MIT family.

Boost has the advantage over "Expat" of being explicitly included in the
SPDX listing with a short name of "BSL-1.0":

 https://spdx.org/licenses/

while Expat doesn't get its own identifier in that list, but instead has
the discouraged "MIT".


This kind of requests should be handled by the policy group first, as 
explained in the base-files FAQ. I'm reassigning the bug.


Thanks.

Re: Bug#1013195: base-files: Please add AGPL-3 license

[Santiago Vila]

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 long text of the license which
also gets duplicated if many binary packages are generated.

For ease of read from FTPmaster it would be preferrable to have the text
in base-files so that it can just be referenced.


This kind of requests should be handled by the policy group first, as 
explained in the base-files FAQ. I'm reassigning the bug.


Thanks.

Re: Bug#924094: base-files: Missing Artistic-2.0 in /usr/share/common-licenses/

[Santiago Vila]

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 instead?

I wished I could refer to a file /usr/share/common-licenses/Artistic-2.0 
instead of copying it.
The original license is on https://opensource.org/licenses/Artistic-2.0


This kind of requests should be handled by the policy group first, as 
explained in the base-files FAQ. I'm reassigning the bug.


Thanks.

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Santiago Vila]

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 package cannot satisfy this requirement it must not
> +unconfigured after being configured at least once.
> +If the package cannot satisfy this requirement it must not
>  be tagged as essential, and any packages depending on this package must
>  instead have explicit dependency fields as appropriate.

More to the point: Packages that may have the "awk" role, which is
considered both essential and virtual, will definitely never work
until configured for the first time, because /usr/bin/awk is handled
by the alternatives mechanism, which runs in the postinst.

In other words, your proposed patch seems completely ok to me, as it
represents (what I think it has always been) Debian Policy accurately.

Thanks.

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Santiago Vila]

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 package cannot satisfy this requirement it must not
> +unconfigured after being configured at least once.
> +If the package cannot satisfy this requirement it must not
>  be tagged as essential, and any packages depending on this package must
>  instead have explicit dependency fields as appropriate.

I think that has always been the spirit of Debian Policy, which is
also consistent with the behaviour of current bootstrap tools.

(Note that it's a paragraph which is talking about upgrades, and
related to the fact that dpkg "unconfigures" a package before
upgrading it).

Thanks.

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Santiago Vila]

> > 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 traditional bootstrapping tools have been doing, and
> it's all kinds of wrong. For example whether a system even uses an
> /etc/passwd is an implementation detail of that system. Some don't
> even have one. If we added support for such a port, then in addition
> to patching the relevant code that directly deals with this, we'd
> need to also adapt all the bootstrappers to cope with this. Instead
> of them just automatically just working out of the box, w/o needing
> to hardcode package names, internal implementation details, etc.

Following such reasoning, the uids defined in /etc/passwd are also an
implementation detail that base-files should not need to know. Moving
such information from base-passwd to base-files and hardcoding it
seems a step in the wrong direction for exactly the same reasons.

> > You want to create a common framework to reuse such knowledge and
> > share it between different bootstrapping tools? Fine, maybe then new
> > bootstrapping tools finally realize that there must be a valid
> > /etc/passwd before configuring anything else.
> 
> That knowledge is already in each relevant package, the passwd stuff
> in the base-passwd package (in Debian) or possibly elsewhere in other
> systems.

So, base-files does not need to know the uids defined in /etc/passwd
because such information is already in the base-passwd package.

> > Please reassign to whatever bootstrapping tool is not doing its job
> > properly. Sorry, but this is starting to annoy me.
> 
> I'm sorry to hear, but TBH, I'm a bit puzzled about your replies. That
> might be due to the apparent conflation of trying to look for a better
> solution to the problem presented, and how to incrementally transition
> to such a bettter place smoothly already right now?
> 
> It's not clear to me whether you oppose the discussion about such
> proposals because you consider the current bootstrapping method the
> ideal solution, or whether you oppose any progressive move towards
> those, as in an all or nothing scenario?

I'm not opposed to discussing new proposals. The current bootstrap
methods may not be ideal, but they are ok to me as far as they do
their job.

My annoyance, as you have rightly pointed out, comes from conflating
the discussion of new proposals with the present problem in the
present bootstrapping tool.

New proposals to bootstrap Debian are welcome here. Trying to fix a
bug in a bootstrapping tool by changing base-files, which is not to
blame for such bug, is annoying me. (So, Helmut, please file a bug
in the bootstrapping tool which does not work for you, and do not
try to fix it here).

I do not exclude the possibility of incremental changes, but the ones
I've heard so far seem steps in the wrong direction to me.


One idea that was floating around was to make dependencies on
essential packages from essential packages explicit instead of
implicit. Does anyone have any idea about how such thing would work?
Would that improve things? Would dpkg and current bootstrapping tools
allow internal simplification or "factoring" if we did that?
Would they still work at all?

Thanks.

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Santiago Vila]

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 it's also fair to say that base-files is exactly a collection of
> the miscellaneous files and bootstrapping actions that no other package
> seems particularly responsible for, so if a new miscellaneous file or a
> new bootstrapping action appears, base-files seems a reasonably natural
> home for it (or at least, more natural than a package that contains
> non-bootstrapping code, for example bash or debianutils).

Maybe, but this is neither a new miscellaneous file nor a new
bootstrapping action. This is yet another bootstrapping tool
forgetting the lessons learned from the other bootstrapping tools.

Helmut Grohne wrote:
> If we agree that this would be the best fix for buster, I volunteer to
> write a patch for base-files to implement that.

No, I do not agree, so please don't.

> How is a bootstrap tool supposed to know
> that it must configure base-passwd before base-files?

In a theoretical level, because it's their job to know such things.

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.

You want to create a common framework to reuse such knowledge and
share it between different bootstrapping tools? Fine, maybe then new
bootstrapping tools finally realize that there must be a valid
/etc/passwd before configuring anything else.
 
But lack of such a common framework is not an excuse to ditch the
definition of essential and start doing things "just in case"
some new bootstrapping tool forgets again that there must
be a valid /etc/passwd before configuring anything else.

Please reassign to whatever bootstrapping tool is not doing its job
properly. Sorry, but this is starting to annoy me.

Thanks.

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Santiago Vila]

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 only be a
> temporary measure until we have a declarative method or other helper that does
> the correct translation instead. But since no such helper exists right now,
> numeric ids are probably the best way to fix this bug for buster.
> 
> I was now als able to trigger this bug in mmdebstrap. Here is how to populate 
> a
> chroot directory with a set of packages that is less than the Essential:yes 
> set
> and based on busybox:
> 
> sudo mmdebstrap --mode=root --variant=custom \
> --include=dpkg,busybox,libc-bin,base-files,base-passwd,debianutils \
> --setup-hook='mkdir -p "$1/bin"' \
> --setup-hook='for p in awk cat chmod chown cp diff echo env grep less ln 
> mkdir mount rm rmdir sed sh sleep sort touch uname; do ln -s busybox 
> "$1/bin/$p"; done' \
> --setup-hook='echo root:x:0:0:root:/root:/bin/sh > "$1/etc/passwd"' \
> --setup-hook='printf "root:x:0:\nmail:x:8:\nutmp:x:43:\n" > 
> "$1/etc/group"' \
> unstable ./debian-unstable-busybox
> 
> As one can see, I had to create a minimal /etc/passwd and /etc/group inside 
> the
> chroot filled with entries for root, mail and utmp for the base-files postinst
> to work. Using mmdebstrap like that is indeed quite a hack right now, so I'm
> not claiming that mmdebstrap should be the reason for base-files to change.

I think from all the above that it should be not only mmdebstrap but
maybe also every other bootstrapping tool the one to create a minimal
/etc/passwd to bootstrap base-passwd.

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, but the same
thing base-files does could be done by any other essential package.

The way I see it, if base-files fails during bootstrapping it's not
because it does not "help" the bootstrapping tool, but because the
bootstrapping tool didn't bootstrap base-passwd in the first place.

> But maybe this is a useful way for you of how to see this problem
> happening for yourself.

If those setup hooks are the workaround for the problem, I see the
problem in this case, and in my opinion creating a minimal /etc/passwd
and configuring base-passwd before base-files would be the optimal way
to fix this particular problem (i.e. moving two of the setup hooks
into mmdebstrap itself).

Now the question would be if we really need to add a paragraph to
Debian Policy, "Recommendations/guidelines for bootstrapping tools",
clearly stating that bootstrapping tools should bootstrap base-passwd
before trying to configure base-files. I think that would be quite
clear by now, but I could be wrong.

Thanks.

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Santiago Vila]

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 software
> components that does not require as much magic as currently has to be supplied
> by tools like debootstrap. The result would not be "hacks here and there" but 
> a
> cleaner and more robust setup procedure.
> 
> So what I want you to take away from this long mail is: maybe we should
> re-think the way we are currently creating a Debian chroot because maybe there
> exists a different approach that would give us benefits that are actually
> important to our users and make maintaining the universal operating system
> easier?

Sounds good in theory, but I'd like to know what kind of new
architecture are you thinking of, how would it be implemented,
or how would it work in practice.

For example, for people bootstrapping new architectures,
we introduced build-stages (afaik now called build-profiles).
(The  in gettext, for example).

Maybe in the same line we could add a special Depends field only
meaningful for bootstrapping tools? Is this the sort of thing you have
in mind?

I would certainly consider a lot cleaner to add a new field to
base-files in the form "Bootstrap-Depends: base-passwd" than
converting all chowns in postinst to use integer numbers.

Thanks.

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Santiago Vila]

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
> > discussion we had about this several years ago.
> 
> multistrap doesn't take care of this and you can provoke a
> base-files.postinst failure this way.

In such case I would say that as a bootstrapping tool it's not doing
its job properly.

The first rule of a bootstrapping tool is that it has to work.
(And there are actually no other rules. As far as it does its job,
you are allowed to do all sorts of dirty hacks).

Bootstrapping tools exist so that we don't have to worry about
dependencies on essential packages. It has always been my opinion that
if we start to do hacks here and there so that bootstrapping tools
work properly, we are already doing it wrong.

> > Can you provide at least a bug number for the bootstrapping tool that
> > apparently still tries to configure all packages at once, or
> > base-passwd and base-files in the same row?
> 
> #924401, but I'm not yet sure which part we need to fix.

Hmm, but that's the present bug.

I meant a bug in a bootstrapping tool.

> [,,,]
> Just because debootstrap encodes a ton of hacks to make things barely
> work (and break every so often) doesn't mean we have to maintain them
> until eternity.

I would say: Just because people writing new bootstrapping tools seem
to forget the lessons learned from previous bootstrapping tools, we
have to learn again what bootstrapping really means: It's not adding
hacks to the normal packages, it's concentrating all the hacks in the
bootstrapping tools, so that we can keep ordinary packages clean of
hacks.

(Or at least that's what I think it was the idea behind the essential
definition).

Thanks.

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Santiago Vila]

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
> | are in the “Unpacked” state.
> 
> When unpacking (but not configuring) a buster or unstable essential
> package set, nothing creates /etc/passwd. Creation of that file is
> performed by base-passwd.postinst. base-files.postinst relies on a
> working /etc/passwd by using e.g. "chown root:root".

I think this is expressed in very generic terms.

To be precise: Who is unpacking (but not configuring) a buster or
unstable essential package set, if not a bootstrapping tool?

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
discussion we had about this several years ago.

Can you provide at least a bug number for the bootstrapping tool that
apparently still tries to configure all packages at once, or
base-passwd and base-files in the same row?

In other words: Is the present bug report to be considered in a
theoretical way, or it is the result of some problem that you actually
found recently with a bootstrapping tool?

(Or maybe it is the result of someone trying to bootstrap a Debian
system/chroot without using a bootstrapping tool at all?)

Thanks.

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Santiago Vila]

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
> | are in the “Unpacked” state.
> 
> When unpacking (but not configuring) a buster or unstable essential
> package set, nothing creates /etc/passwd. Creation of that file is
> performed by base-passwd.postinst. base-files.postinst relies on a
> working /etc/passwd by using e.g. "chown root:root".
> 
> Now we can make a choice:
> A. /etc/passwd is part of base-passwd's interface and base-files is
>right in relying on it working at all times. Then base-passwd is rc
>buggy for violating a policy must. Fixing this violation is
>technically impossible.
> B. /etc/passwd is not part of base-passwd's interface and base-files
>wrongly relies on its presence rendering base-files rc buggy.
> C. Guillem Jover hinted that policy expects every essential package to
>be configured at least once. The current text does not make this
>assumption clear. If it holds, policy would simply say nothing about
>how to bootstrap an essential system, which may be fine. Given that
>we have debootstrap, cdebootstrap, multistrap, and mmdebstrap, it
>seems like specifying the bootstrap interface would be a good idea.
>Unfortunately, I don't exactly understand the bootstrap interface at
>present. In practise, you cannot run postinsts of essential packages
>in arbitrary order.

I think you actually can as soon as the system has been properly
bootstrapped, which is precisely the work of bootstrapping tools.

Can we please reassign this to whatever package is not bootstrapping
the system properly in your case?

Thanks.

Bug#824495: debian-policy: Source packages "can" declare relationships

[Santiago Vila]

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 usually a required workaround but often
not the best solution. I would try to complement the quoted paragraph
with some note or advice saying "try to make it compatible so that
build-conflicts are not really required" or something alike.

Thanks.

Bug#824495: debian-policy: Source packages "can" declare relationships

[Santiago Vila]

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 "painful" here. In this case, a
Build-Conflicts would have told sbuild to uninstall automake during
the "install build-dependencies stage", which is not painful at all.

The real pain comes from not having a build-conflicts at all (because
in such case there was a FTBFS).

> In this particular case, it also seems unnecessary. [...]

In this case, it was unnecessary, yes. The maintainer solved the
problem by calling automake-1.11 by its versioned name. But as far as
this was not done yet, the package had an undeclared build-conflicts.

Anyway, this was the case that made me think about the language used
in policy. The package (as it was) "required" in an absolute sense not
to have automake installed as much as it "required" to have their
build-dependencies installed. That's why "can" or "may" seemed a
little bit strange for the wording to me.

Maybe the relevant paragraph in policy is this one instead:

  If build-time dependencies are specified, it must be possible to build
  the package and produce working binaries on a system with only
  essential and build-essential packages installed and also those
  required to satisfy the build-time relationships (including any
  implied relationships).

To follow with the previous example, does this paragraph imply that if
you call automake by "automake" and you build-depend on automake-1.11
then you should use a build-conflict?

I don't think so, because the "with only [...]" part suggests the
completely minimal chroot approach to building packages.

Thanks.

Bug#824495: debian-policy: Source packages "can" declare relationships

[Santiago Vila]

> > 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 could
> introduce a requirement to use Build-Conflicts into Policy.  We would
> not be able to determine whether we were making packages buggy by doing
> that.

Sorry, I forgot some details about the case that prompted me to file
this report:

I was building all the packages in stretch, and to save time and
bandwidth for each build, I installed debhelper in my chroot
(as nearly every package uses it).

The source package failed to build from source if you had "automake"
installed in the chroot. At the time, automake was installed by
default when you installed debhelper.

So it built ok only if you take the ultraorthodox path of having a
completely minimal chroot, but it would fail for anybody who, like me,
also installed debhelper and its default dependencies in the chroot.

What I would like to avoid is maintainers recommending or even
*suggesting* the user to uninstall the conflicting package
as a way to "solve" the problem, as it happened here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824011

Maybe I was a little bit rude at the time by changing the severity
while discussing, but I would also consider rude that a maintainer
even suggests that this FTBFS problem is user's fault and not a
packaging bug.

So: What about "packages should declare Build-Conflicts when the
build-conflict happens against a very common build-dependency"?
(Or something like that).

If we don't do anything like that, not even a recommendation, an
example, or a typical use-case for build-conflicts, maybe we could
declare that the only acceptable way to build packages is to have a
completely minimal chroot and declare build-conflicts obsolete...

Thanks.

Re: base-files - please consider adding /usr/share/common-licenses/Unicode-Data

[Santiago Vila]

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
> Debian if you are interested. [...]

Hello. According to /usr/share/doc/base-files/README, the decision to
include a license or not is delegated to the Debian Policy Group, so
I'm reassigning this bug.

Thanks.

Bug#299007: Transitioning perms of /usr/local

[Santiago Vila]

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 subdirectories created
by the package should have permissions 755 and be owned by "root:root"
if /etc/staff-group-for-usr-local does not exist, and they should have
permissions 2775 (group-writable and set-group-id) and be owned by
"root:staff" if /etc/staff-group-for-usr-local does exist.


Thanks.

Bug#299007: Transitioning perms of /usr/local

[Santiago Vila]

Hello Debian Policy people.

This is to tell you that I've finally changed base-files in unstable
to not create /etc/staff-group-for-usr-local anymore on new installs,
following the TC decision about this in Bug #484841 and the transition
plan explained in the file /etc/staff-group-for-usr-local itself.

If we decide to continue with group staff, next step would be to make
sure packages follow the plan by the time buster is released as
stable.

With a little bit of help from debhelper maintainer (on which most
packages build-depend) and people doing Continuous Integration
(piuparts), I truly believe this would be a feasible goal for buster.

OTOH, if we decide to forget about group staff completely
(as I read Ubuntu did), we would still need to ensure that
packages forget about group staff as well.

[ I, for one, would prefer to reunificate with Ubuntu in this issue
  and get rid of staff completely, but this is just my opinion ]

Should we maybe ask TC again about this? A lot of time have elapsed
since they made their decision, and the world has changed a lot since
then.

Thanks.

Re: Bug #882628: base-files: Please ship CC0 in /usr/share/common-licences

[Santiago Vila]

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.

Bug#299007: Transitioning perms of /usr/local

[Santiago Vila]

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 group-writeable by staff, but Russ says that you would
> like your transition plan to be documented in Policy.  Is this still
> true?  Would you be able to propose a patch against the Policy git repo
> as it currently stands?

I had some items in my todo list regarding this bug and I have to say
I'm really sorry for not doing them. What I had in mind was:

* Ensure that packages conform to the transition plan.
* Submit bugs against packages that do not.
* Contact Niels in case some debhelper change was required for this.

However:

I wonder if we really want to do all that in 2017. The staff-writable
/usr/local for a "sysadmin assistant" was an interesting idea twenty
years ago. Today, we would give a sysadmin assistant an entire
virtual machine to play with, and would probably not bother with this.

So my question would be: Do we really need to support both ways
to handle /usr/local at this point?

And for practical purposes: Will packages really stop fiddling with
/usr/local once I remove /etc/staff-group-for-usr-local in buster
initial install? I have been hesitant of doing this move because
I never took the time to recollect data that would tell me whether
or not it would work.

Thanks.

Bug#835451: debian-policy: Building as root should be discouraged

[Santiago Vila]

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 have to be made dependencies of the build target (which can only
> > have deps but no own instructions).
> > 
> > And if that makes packages buggy, then they are actually quite buggy,
> > because the build-a ... build-n get executed in a fakeroot concept by design
> > of dpkg-buildpackage. And IMHO this should definitely be avoided.
> 
> Just to be clear, I do agree with you that this situation where they are
> deps of the binary target is bad.
> 
> Interested to hear what Santiago thinks.

Hi.

I have to agree with everything Mike Gabriel said. The first patch
you proposed seems insufficient to me.

All the building stuff should be made in the build target, and we
might better not allow any of the binary target to depend on any of
the build targets, as the current policy seems to allow.

Thanks.

Bug#835451: debian-policy: Building as root should be discouraged

[Santiago Vila]

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 +0200, Santiago Vila wrote:
> > 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 (or more) targets (build-a and build-b or whatever) for
> >  each of the ways of building the package, and a build target that does
> >  nothing. The binary target will have to build the package in each of
> >  the possible ways and make the binary package out of each. 
> > 
> > Actually, no, I don't think that's "good enough".
> > 
> > We should better avoid building packages as root (including fakeroot).
> 
> We already have in policy both:
> 
> (i) The build target must not do anything that might require root
> privilege.
> 
> (iI) The binary targets must be invoked as root [or fakeroot].
> 
> However, in the paragraph you quoted, there is a loophole: if the
> build-a and build-b targets are not invoked by the build target, instead
> directly invoked by the binary target, then (i) does not apply, and
> indeed (ii) applies and they will be invoked as root.
> 
> Is that why you want to delete that paragraph?

Yes, indeed!

There is some background in libtool Bug #806654. It was a really
strange build failure and it was not self-evident that the failure was
the result of building as root. In this particular case, the package
had only standard build-indep and build-arch targets, but it made me
to read policy again and that's when I found about the "good enough"
thing.

Thanks.

Bug#835452: debian-policy: Deprecating dependency of "binary" on "build"

[Santiago Vila]

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 point at all:


* Autobuilders *always* invoke the build-* targets first.

* dpkg-buildpackage *always* invoke the build/build-* target first.

* AFAIK, we have never actually supported this way of building packages,
and I doubt it would be a good idea to start supporting it now. We
should preferably have only one standard way of building a package
(debian/rules clean && debian/rules build && debian/rules binary),
(and its -arch and -indep variants), not two, of which one of them is
tested over and over again by the autobuilders every day and the other
is never tested.

* Building as root should be discouraged.



My proposal to fix this is to remove the requirement that "binary"
depends on "build", including the "rationale".

I don't know if this proposal will seem controversial, because we have
been doing that for ages, so please let us consider all the pros and
all the cons.

I guess that no package will be affected by this change, because in
general removing a requirement does never make policy compliant
packages to become non-compliant.

Thanks.

Bug#835451: debian-policy: Building as root should be discouraged

[Santiago Vila]

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 (or more) targets (build-a and build-b or whatever) for
 each of the ways of building the package, and a build target that does
 nothing. The binary target will have to build the package in each of
 the possible ways and make the binary package out of each. 

Actually, no, I don't think that's "good enough".

We should better avoid building packages as root (including fakeroot).

Otherwise we will find nasty surprises like the libtool Bug #806654,
where a badly written debian/rules made the whole build to be done as
root, including the tests, which in turn made the build to fail.

My proposal to fix this would be to remove the quoted paragraph
entirely.

Then the paragraph above it would prevail and it would be the only
policy regarding this:

 The build target should perform all the configuration and compilation
 of the package. [...]


I don't know if there are a lot of packages building things as root,
but at the very minimum we should deprecate that and stop saying it is
"good enough".

Thanks.

Bug#824495: debian-policy: Source packages "can" declare relationships

[Santiago Vila]

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 sense that this is the vocabulary that
the maintainer is allowed to use when writing control files.

To my surprise, however, today a maintainer has quoted this "can" word
as a rationale for a missing Build-Conflicts not to be a bug of serious
severity:

  "No _must_ directive here. It is not a Policy violation if you don't
  use Build-Conflicts."

If my idea that policy is just describing the vocabulary is close to
reality, I would perhaps suggest something like this:

  The following relationsips are available for source packages to
  express the fact that they require certain binary packages to be
  installed or absent at the time of building the package.

but then it would be nice to state somewhere later that Build-Depends
and Build-Conflicts are not just "optional" but mandatory when the
referenced packages are either required to be present or required to
be absent.


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.

Is there any rule to decide what to put in build-conflicts?

Thanks.

Re: debian/copyright in source package

[Santiago Vila]

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 to the
> binary package, it might violate some licenses and such the package may not
> be distributed by Debian or may not be used on Debian systems.
> 
> As the normal workflow of packaging is to collect the copyright and license
> information in debian/copyright and copy that file into the binary package
> during build, a missing file might make the package unusable. Of course, not
> in a technical manner.

I think you are missing the point completely.

I'm talking about packages shipping *proper* copyright files in their .deb
that are generated by debian/rules at build time.

There is absolutely no license, copyright or dfsg-freeness problem in
doing that, and there is also no usability problem at all justifying
the "important" severity.

Moreover, normal workflow != mandatory.

If you want to make it mandatory, what you should do is to modify
policy so that it reads "must", not submitting a lot of similar bugs
with inflated severity.

> Anyway, in the light of source only uploads, how shall the copyright and
> license information of the binary packages be verified, if there is no
> debian/copyright? Either the maintainer or the ftpteam has to do the work.
> Given that the package output of about 1000 maintainers needs to be checked
> by just a few members of the ftpteam, the burden should be distributed on
> the larger group. And experience shows that there is a check needed to
> fulfill the DFSG.

If that's really a problem, I think it would be fair to require that
the very first time a package is uploaded, it's *not* done in
source-only form. This way you will always have a copyright file
available without having to build the package yourself.

But there is something I don't understand. Do you *just* verify that
there is a debian/copyright file in the source? You don't verify that
it matches the actual copyright notices in the several *.c files etc?

Surely that a mandatory debian/copyright file in the source might
simplify your work a little bit (which is why you should try to modify
policy in the first place), but such kind of help would be just a
small fraction of the license and copyright checking anyway.

So, to summarize, I don't think this is such a big problem.

Re: debian/copyright in source package

[Santiago Vila]

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 documentation says that important means "a bug which
has a major effect on the usability of a package, without rendering it
completely unusable to everyone".

Not having a debian/copyright file in the source package does not
affect usability of the package in *any* way.


So: Why is this a "should" at all?

Re: debian/copyright in source package

[Santiago Vila]

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.

Re: debian/copyright in source package

[Santiago Vila]

[ 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 fix the original LICENSE.

In this particular case, LICENSE is now MIT-style and not a big file
anymore, as it used to be, so there is not a great benefit in the file
being generated automatically. It will be easy to stop doing that, and
that's what I will probably do.

The case explained by Simon is more elaborated and a *lot* more
interesting.

> >I know that we usually treat packages as "whole works", but in theory
> >a package might well be an aggregation of different programs having
> >different copyright and licenses, in which case it would be
> >theoretically possible to have a different copyright file for each of
> >them.
> 
> Yes, but wouldn't this be valid only for binary packages?
> [...]

In the hypothetical case I imagine, the copyright files for the binary
packages would be different, and then you can't make the one in the
source to be a copy of *any* of them, as policy requires.

On Sun, Aug 16, 2015 at 10:41:16AM -0700, Russ Allbery wrote:
> I think this has come up before, and my recollection of where we ended up
> in the past is that there probably isn't any *legal* reason to require
> debian/copyright in source packages.  However, there's a substantial
> *practical* reason, namely that the existing ftpmaster tooling depends on
> the existence of a source debian/copyright file for the way that they do
> license reviews, and that some tooling and process changes would be
> required before we can relax this requirement.

Yes, I think this practical reason (the ability to extract
automatically copyright files from source packages) is the main reason
why debian/copyright is required.

So we could just add it to policy as a rationale.

Thanks.

Re: debian/copyright in source package

[Santiago Vila]

> >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 useless duplication of license text in the source
package.

I know that we usually treat packages as "whole works", but in theory
a package might well be an aggregation of different programs having
different copyright and licenses, in which case it would be
theoretically possible to have a different copyright file for each of
them.

debian/copyright in source package

[Santiago Vila]

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 this mass bug filing?

2. Why would policy say "should" instead of "must", if we then do not
allow for exceptions? (packages generating copyright file at build time).

Thanks.

Re: Timezone name in Debian changelog format

[Santiago Vila]

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 should just drop it instead of fixing the
> regex. Comments?

Go ahead. As you have just shown, there are plenty of good reasons to
drop it and little to keep it.

[ I did a little experiment and could not find a single timezone name
  in my 18 years of changelogs ].


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150626085658.ga13...@cantor.unex.es

Bug#746514: Autoreconf during build

[Santiago Vila]

+  If your package includes the scripts config.sub and
+  config.guess, you should arrange for the versions
+  provided by the package autotools-dev be used
+  instead (see autotools-dev documentation for
+  details how to achieve that).  This ensures that these files can
+  be updated distribution-wide when introducing new architectures.

Please don't word policy that way.

This does not solve the problem, only hides it, and it's the way to
forget the problem instead of actually solving it.

With or without this policy, porters should have to hack packages
anyway, so this is only useful for packages which are not updated
upstream often enough.

I think such a strong requirement ("should") does not belong to policy.
Make a recommendation if you wish, but making mandatory that those
files are updated at build time would be like making mandatory the use
of debhelper (which we don't, because we want to keep the freedom to
not use a helper package).

Those files were created with portability in mind. If we have to
update those files each and every time at build time, there is a clear
design flaw. Once again, we should talk with GNU people about this
problem.

(Or do something that this proposed policy does not encourage, which
is to continue to flood them with reports saying "Please update
config.* files", maybe that way they would realize that the current
status is highly suboptimal).


My suggestion:


  Packages using config.sub and config.guess should ship recent
  versions of those files, or, alternatively, arrange for the versions
  provided by the package autotools-dev to be used
  at build time.


BTW: The most recent version of those files are now GPLv3 + exception.

Perhaps we should say something in policy about ensuring that the
package may be built with the new files instead of automatically and
blindly doing so.

Thanks.


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1505112028460.5...@cantor.unex.es

Bug#784248: developers-reference: wheezy is Debian 7 (7.0 is only the first release)

[Santiago Vila]

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 a/developers-reference-3.4.14/pkgs.dbk 
b/developers-reference-3.4.14/pkgs.dbk
index 2daf418..8e2d523 100644
--- a/developers-reference-3.4.14/pkgs.dbk
+++ b/developers-reference-3.4.14/pkgs.dbk
@@ -2157,7 +2157,7 @@ this, a version of the form
 
+debXuY
 should be used, where X is the major release number,
 and Y is a counter starting at 1.
-For example, while Wheezy (Debian 7.0) is stable, a security upload to stable 
for
+For example, while Wheezy (Debian 7) is stable, a security upload to stable for
 a package at version 1.5-3 would have version
 1.5-3+deb7u1, whereas a security upload to Jessie would get
 version 1.5-3+deb8u1.


Thanks.


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1505041539020.8...@cantor.unex.es

Bug#784244: developers-reference: suffix +deb8u1 is for stable uploads, even if they are not a NMU

[Santiago Vila]

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 is a little bit confusing.

A simple way to fix this would be to simply use the "upload" word
instead of NMU, as in the following patch:

diff --git a/developers-reference-3.4.14/pkgs.dbk 
b/developers-reference-3.4.14/pkgs.dbk
index 5a34b95..2daf418 100644
--- a/developers-reference-3.4.14/pkgs.dbk
+++ b/developers-reference-3.4.14/pkgs.dbk
@@ -2157,9 +2157,9 @@ this, a version of the form
 
+debXuY
 should be used, where X is the major release number,
 and Y is a counter starting at 1.
-For example, while Wheezy (Debian 7.0) is stable, a security NMU to stable for
+For example, while Wheezy (Debian 7.0) is stable, a security upload to stable 
for
 a package at version 1.5-3 would have version
-1.5-3+deb7u1, whereas a security NMU to Jessie would get
+1.5-3+deb7u1, whereas a security upload to Jessie would get
 version 1.5-3+deb8u1.
 
 


Thanks.


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1505041527440.8...@cantor.unex.es

Bug#759260: [summary] Bug#759260: removal of the Extra priority.

[Santiago Vila]

On Tue, 18 Nov 2014, Charles Plessy wrote:

> Le Mon, Nov 17, 2014 at 03:55:26PM +0100, Santiago Vila a écrit :
> Hi Santiago,
> 
> practically speaking, how do you or others use the Optional priority
> to check that a package is not directly or transitively conflicting
> with another package ?  First, according to debcheck
> (https://qa.debian.org/debcheck.php?dist=sid&list=main-only-priority&arch=ANY)
> there are thousands of packages whose Priority setting violates the
> current policy.
> 
> Second, tools such as "apt-get --simulate" are very efficient at
> checking if the installation of one package will need or trigger the
> removal of another one.  In which case would it be more efficient to
> check the priority instead, especially given the first point above ?

We can't obviously rely on the current rule if it's violated, but
violations of the rule are just a sign that we didn't try hard enough
to comply with it, not a sign that the rule is useless and we should
drop it.

> Can you give concrete examples where the Extra priority has been instrumental
> for you as a user or a developer, in a way that has no practical alternative ?
> Or said differently, what would break concretely for you if tomorrow the
> Optional and Extra priorities were merged ? 

As it has been pointed out by others, whenever we have a set of
mutually conflicting packages performing the same task, the package
having optional priority is the one that we recommend among them.

It is a way to tell the user "in doubt, use this one".

For example, there was a time in which there were several NFS servers
available. The only one who survived, nfs-kernel-server, is the only
one that was optional, so I installed that one when I needed a NFS
server a long time ago.

If we had not the extra priority, I would have to look at
popularity-contest or similar data. I think that it is a good thing
that we have a way to recommend packages which is independent from
"what everyone else is using".

Thanks.


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1411181237060.17...@cantor.unex.es

Re: Bug#758234: transitive dependencies

[Santiago Vila]

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 add a paragraph in policy which explictly
states that all libraries are optional by default.

However, I don't see what do we gain by making libc6 optional. I see
that as a too much radical change.

Would be very difficult to automate that an essential[*] package
depending on another package (library or not) makes the other package
automatically required? Would that be harmful? (I fail to see how it
could be harmful).

[*] Only essential packages, not virtually essential packages like awk
or pseudo-essential packages like the alternate dependencies of "init".

Thanks.


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141117153932.ga20...@cantor.unex.es

Bug#759260: removal of the Extra priority.

[Santiago Vila]

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
*dropping* the extra priority, other than "it's not useful for me".
Well, it may be useless for you but it's still useful for me.

IMHO, whatever harm may cause the extra priority (if any) should be
*much* better documented than this. Please do not limit yourself to
"addressing the objections".

Thanks.


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141117152312.gb20...@cantor.unex.es

Bug#759260: [summary] Bug#759260: removal of the Extra priority.

[Santiago Vila]

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, no concrete example (that is, not
> just a though experiment or a single exploratory attempt) of relying
> on this co-installability was given.

No. There is a little bit (or a lot) of confusion here.

It's true that the extra priority, together with the rule saying there
should not be conflicts among optional or higher packages, would allow
installing all the optional packages.

But being able to install all the optional packages is not the *goal*
itself.

The purpose is to allow the user to install as many optional packages
as he/she wants without having to bother with conflicts.

Obviously, if the set of optional or higher packages has the priority
that you can install all of them (theoretically), then it follows
naturally that every subset of such set which is closed regarding
dependencies also has such property.

As I said the day before yesterday in another thread, installing all
the optional packages (which may be technically difficult because of
the current archive size) is not actually *required* for this property
to be useful.

Therefore I object to dropping the extra priority.

Thanks.


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141117145526.ga20...@cantor.unex.es

Bug#758234: transitive dependencies

[Santiago Vila]

On Sat, Nov 15, 2014 at 09:09:06AM +0100, Matthias Urlichs wrote:
> If I read #759260 correctly, Gerrit Pape  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
> clearly is, not because
> 
> * there's no technical reason (any more) to require this fix-override-file
>   business
> * it installs superfluous libraries when you exclude something when
>   debootstrap-ing
> * we forget to de-prioritize libraries when they're no longer needed in
>   the high-priority set

If those are the real reasons, then let's drop the rule only for
*libraries*, but not for every other package.

I would propose something like this:

 Packages must not depend on packages with lower priority values
 (excluding build-time dependencies).  In order to ensure this, the
 priorities of one or more packages may need to be adjusted.

 The previous rule is waived for libraries, which will generally be of
 "optional" priority, even if packages required, important or standard
 depend on them.

In fact, I'm not sure that making libc6 optional is a good idea.

BTW: A lot of years ago I tried to make the override file to follow
the rules without success. What about automating this procedure first?

> so I'd like to specifically invite arguments against this change here,
> instead of digging through archives and inferring any opponent's reasoning.
> 
> > Regarding your proposed change, I wonder what is the practical case for
> > forbidding conflicts with higher-priority packages.  Could you give an 
> > example
> > showing that it is strictly necessary ?
> 
> I do not know of a concrete example. I did infer, from previous discussion,
> that debootstrap et al. can't handle such conflicts. It seems prudent to
> proactively forbid such dependencies, rather than deal with a last-minute
> nonfixable bug filed on debootstrap.

The rule about conflicts, AFAIK, has nothing to do with debootstrap.

It is a rule that, when followed, makes the archive to have a very
good property: You can install as many optional packages as you want
without fear of conflicts. In fact, you could in theory install every
package which is >= optional (however, actually doing this[*] is not a
requisite for the rule to be useful).

I think this rule is useful and we should keep it.

[*] If I remember well, Dale Scheetz once managed to do that, but it
was a lot of time ago and the number of packages was a lot lower.


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141115093529.ga27...@cantor.unex.es

Re: Bug#758234: it's actively harmful

[Santiago Vila]

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 the following set of packages:

+ Packages of required priority.
* Packages of important or higher priority.
* Packages of standard or higher priority.

and all those sets are self-consistent (i.e. they don't have
dependencies outside the set).

I think this is a useful and nice property, but I don't know how many
people rely on it.

> The only practical effect of these priorities I can recognize is that
> apt* refuses to remove Essential packages without asking a question
> which reminds me what the Shift key is for.¹²

Minor clarification: Essential is a flag, not a priority.

Essential packages are almost always required, but they may also be
extra if they Conflicts/Replaces an already existing essential package,
as an alternate implementation for the same functionality (not that there
are a lot of packages like that, but they are not excluded by policy).

In either case, it is the essential flag, not the required priority,
what makes apt-get to ask you enter the phrase "yes, i agree this is
very bad".

Thanks.


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141030105116.ga2...@cantor.unex.es

Re: Bug#758234: it's actively harmful

[Santiago Vila]

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 justify their own priority via the "wtf, why isn't
> this installed?" rule of thumb, like libc6.

Actually, we don't need a rule like that for libc6, because lots of
essential packages depend on it.

We would only need to say "wtf, why isn't this installed?" for a
library that works like a plugin (i.e. a library on which no other
packages depend).

> >> [footnote: This ensures that a
> >> # high-priority package transitioning to a new library dependency
> >> # does not result in both the old and new libraries being installed
> >> # on new systems, due to the old library's priority remaining high.]
> > 
> > However, I don't like the wording of the footnote.
> > 
> > Why would the old library's priority remain high to begin with?
> 
> To have a concrete example to talk about, let's say cron (Priority:
> important) moves from using libstuff0 to using libstuff1.
> 
> If libstuff0 and libstuff1 both come from a "libstuff" source package,
> but you have more than one apt source - e.g. stable on a mostly testing
> system - then your apt can still see the older libstuff0 binaries, with
> the "important" priority that was appropriate when cron/stable depended
> on them. I believe this means it won't automatically get rid of libstuff0?

I think we don't even need to consider more than one apt source to see
the problem.

We could just imagine the case where a user changes "stable" to
"testing" everywhere in sources.list and then upgrades to testing.

Whatever solution to the problem of "getting rid of unused libraries"
in this simplified case would probably be a solution for the case of
mixed apt sources as well.

> If libstuff0 and libstuff1 are in parallel stuff0, stuff1 source
> packages (like Gtk2 and Gtk3), it is not clear to me how the ftp team
> should be expected to know that libstuff0 should be demoted from
> important to optional, or when would be the correct time to do so.

A good rule to follow if we keep current policy would be that
libraries should always have the lowest priority possible
(but >= optional) that makes the rule

"packages should not depend on others with lower priority values"

to be true.

The rule would be, of course, applied independently for each
distribution (stable, testing, unstable).

I believe there would be plenty of room for automation here.

> It could equally well be a core package transitioning from one
> command-line tool to another (dpkg moving from lzma to xz), or from
> command-line tool to library (dpkg's tar.xz support again), or changing
> its implementation to not need one of its old dependencies (systemd used
> to require libdbus-1-3, but has switched to its own D-Bus implementation).

I agree that there may be a lot of different cases, but many, if not
most of them should probably be automated.

> > It sounds as "Lack of manpower in the FTP team forced us to change the
> > rules about package priorities, since they did not change priorities
> > often enough".
> 
> Is your intention that the maintainer of libstuff would track the
> transition and buildd status, somehow work out when libstuff0 no longer
> qualified for important priority, and file ftp.debian.org bugs to demote
> it?

AFAIK, that's what we are already doing, except that it's not always
the maintainer of libstuff the one who tracks the priorities to be
changed and submit the bugs.

> Or that the ftp team determine (in some hopefully automated way)
> that libstuff0 no longer qualifies for important, and demote it? Or what?

I think some automation on this issue would benefit everybody, yes, at
least while we keep the current rules regarding priorities.

My point is that there may be legitimate and valid reasons to change
the rules about priorities, but "we didn't automate enough" should not
be one of them.

Thanks.


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141029153705.ga8...@cantor.unex.es

Re: Bug#758234: it's actively harmful

[Santiago Vila]

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: https://lists.debian.org/20141029124427.gb4...@cantor.unex.es

Re: Bug#758234: it's actively harmful

[Santiago Vila]

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 it. In particular, shared libraries should normally
> # have a low priority, even if required or essential packages
> # happen to depend on them.

If we are going to take that route, we might just make all libraries
optional as a general rule.

> [footnote: This ensures that a
> # high-priority package transitioning to a new library dependency
> # does not result in both the old and new libraries being installed
> # on new systems, due to the old library's priority remaining high.]

However, I don't like the wording of the footnote.

Why would the old library's priority remain high to begin with?

It sounds as "Lack of manpower in the FTP team forced us to change the
rules about package priorities, since they did not change priorities
often enough".

I hope that's not the real reason behind this proposal, because that
would be a problem by itself that should be addressed separately.

Thanks.


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141029124144.ga4...@cantor.unex.es

Re: Policy regarding /etc/profile.d

[Santiago Vila]

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 package is
> to hook into shell startup and reconfigure the shell. What would you
> suggest that they should do instead?

We can make policy not to use profile.d, as a general rule, and then
require that people ask for exceptions (as we already do for
Pre-Depends) before introducing new files in /etc/profile.d.

In the examples you quoted, the permission would naturally be granted.


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015111211.ga9...@cantor.unex.es

Policy regarding /etc/profile.d

[Santiago Vila]

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 have to be set in a system-wide
 configuration file like /etc/profile, which is not
 supported by all shells.)

was that profile.d was never intended to be used by Debian packages,
only by the final user.

[ The profile.d directory was finally added because it was required by
  some LSB compliance test ].

But today I've just realized that what I feared is happening: package
maintainers have started to use profile.d "because it's now supported":

$ zcat Contents-amd64.gz |grep etc/profile.d|sort -k 2
etc/profile.d/Z99-cloud-locale-test.sh  admin/cloud-init
etc/profile.d/modules.sh
devel/environment-modules
etc/profile.d/tinyos.sh devel/tinyos-source
etc/profile.d/alc_env.shelectronics/alliance
etc/profile.d/alc_env.csh   electronics/alliance
etc/profile.d/qmf.sh
libs/libqmfmessageserver1
etc/profile.d/vte.shlibs/libvte-2.90-common
etc/profile.d/vte-2.91.sh   libs/libvte-2.91-common
etc/profile.d/Z97-byobu.sh  misc/byobu
etc/profile.d/PackageKit.sh 
misc/packagekit-command-not-found
etc/profile.d/undistract-me.sh  misc/undistract-me
etc/profile.d/sendfile  net/sendfile
etc/profile.d/SBMLToolbox.shscience/sbmltoolbox
etc/profile.d/bash_completion.shshells/bash-completion


Do we need a paragraph in policy saying explicitly "you should not use 
profile.d"?

Thanks.


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1410150105200.17...@cantor.unex.es

Bug#299007: Group staff in /usr/local: Moving forward

[Santiago Vila]

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:

* On upgrades:
   from version < SOMEVERSION, create /etc/SOMEFILE.
   from version >= SOMEVERSION, do nothing.
* On new installs, create /etc/SOMEFILE-

Then we amend policy so that it reads like this:

* Packages creating directories or putting files in /usr/local should:
- Depend on base-files >= SOMEVERSION
- Check if /etc/SOMEFILE exists.
- If it exists, do things as current policy says.
- If it does not exist, create directories 755 and root:root.

After we change policy, we could start filing bugs, but they do not
need to be RC yet.

Instead, we wait for wheezy to be released.

After the release of wheezy, we modify base-files in this way:

* On upgrades, same as before:
   from version < SOMEVERSION, create /etc/SOMEFILE.
   from version >= SOMEVERSION, do nothing.
* On new installs, do nothing (i.e. stop creating the file).

And this is when we consider the bugs to be RC for wheezy+1, but we
would have plenty of time to fix them (all the development stage for wheezy+1).

SOMEFILE would be something like /etc/staff-group-for-usr-local and it
could even be self-documenting ("This file exist so that bla bla. if you
remove this file after upgrading to wheezy+1, directories under /usr/local
will be created root:root and 755").

I believe this plan makes the transition as smooth as possible. Please
tell me if you see any flaw in it.

I'll be happy to prepare a patch against policy with the required wording
(and of course, do the required changes in base-files).

Thanks.



-- 
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/alpine.deb.2.02.1205141407200.13...@cantor.unex.es

Re: Bug#621462: base-files: missing AGPL-3 license

[Santiago Vila]

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.


-- 
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/alpine.deb.2.00.1104071030440.1...@cantor.unex.es

Re: Bug#620674: base-files: Please include the text of the Open Font License (OFL) in /usr/share/common-licenses

[Santiago Vila]

reassign 620674 debian-policy
thanks

On Sun, 3 Apr 2011, Christian Perrier wrote:

> Package: base-files
> Version: 6.1
> Severity: normal
> 
> The Open Font License is quite universally considered as meeting the
> DFSG. Indeed, several font packages in Debian main provide fonts
> distributed under that license.
> 
> Having the full text of OFL distributed in /usr/share/common-licenses
> would avoid including the text of the license in these packages.

According to base-files FAQ, I do not decide about this. The debian
policy group does. Hence the reassign.

Thanks.


-- 
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/alpine.deb.2.00.1104041125160.4...@cantor.unex.es

Re: Bug#608324: please add Affero license to /usr/share/common-licenses

[Santiago Vila]

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 http://ftp.gnu.org/gnu/Licenses/agpl-3.0.txt
> Could you please add it?

Hello Ana.

A long time ago I decided not to decide about this myself. Instead, 
debian-policy does.
You will find a longer explanation in base-files FAQ.

Thanks.


-- 
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/alpine.deb.2.00.1101061726380.20...@cantor.unex.es

Bug#436105: suggestion to add GPL-1 as a common licence

[Santiago Vila]

On Tue, 29 Jun 2010, Russ Allbery wrote:

> Russ Allbery  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 merge
> > conflicts with the BSD diff proposed earlier today and because it's
> > fairly obvious, although I can if people would prefer.
> 
> > Objections or seconds?
> 
> This has now been merged for the next Policy release.  Santiago, when you
> get a chance, could you release a new version of base-files that includes
> the GPL version 1 in common-licenses?  Thank you!

Thanks a lot, Russ.

GPL-1 is now in common-licenses in base-files 5.8.



-- 
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/alpine.deb.2.00.1007051916020.2...@cantor.unex.es

Bug#284340: Please remove reference to UC in BSD license

[Santiago Vila]

On Sat, 12 Jun 2010, Russ Allbery wrote:

> Russ Allbery  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 merged for the next release.

Noted, thanks.

I assume we will have to wait some time before we can remove the
license itself from base-files (i.e. until all packages stop
referencing the file).



-- 
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/alpine.deb.1.10.1006141253420.11...@cantor.unex.es

Bug#436105: suggestion to add GPL-1 as a common licence

[Santiago Vila]

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 a bunch of copies of the GPL
> version 1.  The usage of the license is high enough to qualify for
> common-licenses under our normal criteria: long license, used by over 5%
> of the binary packages in the archive, and used in packages that are
> installed on every system (perl-base).
> 
> 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 merge
> conflicts with the BSD diff proposed earlier today and because it's fairly
> obvious, although I can if people would prefer.

Ok, I agree that it would a good idea to include GPL-1 in common-licenses
because of the high number of packages still using it.

[ Therefore, please clone or reassign this bug back to base-files ].


But please let us not speak about "implicit relicensing". There is no
such thing as "implicit relicensing", the same way there is no such
thing as "implicit licensing" (do don't allow packages in Debian not
having a proper license, do we?).

The blurb in debian/copyright has usually two parts.

The first part might have some legal value (or not, if we consider it
might have typos and the only binding license is the one in orig.tar.gz).

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2, or (at your option)
   any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

The second part is for *informational purposes* only and we should not
pretend it has legal value, not even in implicit sense.

   You should have received a copy of the GNU General Public License
   along with this program; if not, write to the Free Software Foundation,
   Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.  */

The FSF itself has recently changed the "informational purposes" part
and they now point to the Web.

Then we usually add this little blurb:

On Debian GNU/Linux systems, the complete text of the GNU General
Public License can be found in `/usr/share/common-licenses/GPL'.

which is an addon to the previous paragraph, so it's for informational
purposes as well.

Thus, I see no reason to use a versioned license when the license says
"version foo or later". If we say "GPL is here" and there is a policy
that GPL is a symlink that always point to the latest version, then
the paragraph saying "GPL is here" is equivalent to "The latest
version of GPL is here". That's a fact. No relicensing anywhere.

I know this is not directly related to inclusion or not of GPLv1 in
common-licenses, but as people keep talking about "implicit relicensing"
I wanted to point that IMHO such thing does not exist.

Thanks.



-- 
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/alpine.deb.1.10.100601450.12...@cantor.unex.es

Bug#582495: debian-policy: extend UID range of user accounts

[Santiago Vila]

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: 
http://lists.debian.org/alpine.deb.1.10.1005211213440.25...@cantor.unex.es

Bug#582495: debian-policy: extend UID range of user accounts

[Santiago Vila]

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
> > where we start numbering new user accounts from 65536 by default, instead of
> > from 1000.
> 
> Something probably best left until after Squeeze!  I think the
> simple check we have now will be robust enough until after then.

Alternatively, we could try to improve the current status a little bit
for squeeze.

(A system admin with about 45000 users in his system asked me about
the new /etc/profile and the apparently arbitrary limit of 2).


The block 3-5 is reserved *by us*, so we can free it for user
accounts easily:

--- a/policy.sgml
+++ b/policy.sgml
@@ -5849,7 +5849,7 @@

  
 
- 1000-2:
+ 1000-5:
  

  Dynamically allocated user accounts.  By default
@@ -5860,11 +5860,6 @@

  
 
- 3-5:
- 
-   Reserved.
- 
-
  6-64999:
  



Known affected packages: adduser, base-files
Fix: Trivial: s/2/5/

I'm looking for seconds for this proposal.



-- 
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/alpine.deb.1.10.1005211154240.25...@cantor.unex.es

Re: Bug#569219: Document transitional and meta-packages

[Santiago Vila]

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 information, so they can decide to remove some 
> to save disk space and to remove useless packages from the system.
> 
> I propose to clearly state a package is a meta-package or a transitioanl 
> package in the long description. This is a common practice already.


For the purpose of removing useless packages, I would propose that
transitional packages are always "priority: extra" and "section: oldlibs".

That would make deborphan to mark them as "packages that may be removed".


-- 
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/alpine.deb.1.10.1002251119540.10...@kolmogorov.unex.es

Re: Bug#565884: Please include CeCILL* licenses in common-licenses

[Santiago Vila]

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 would 
> benefit from having them in /usr/share/common-licenses.
> 
> [1] http://www.cecill.info/licences.en.html

The base-files FAQ says this is something to be decided by the
debian-policy group, so even if this bug already generated a small
amount of discussion, I'm reassigning it to debian-policy.

Thanks.


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#541703: base-files: Please include FreeBSD license

[Santiago Vila]

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 save any space by
putting it in common-licenses, but it's your decision ].

Thanks.


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#538392: group staff: moving forward

[Santiago Vila]

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.
> 
> The group for the directories can still be staff, it should just not
> be writable by group staff by default [but configurable by users to
> be, with that configuration respected.]

No need to add configuration stuff. If a user wants something different
than the default, he/she can easily make a chown and a chgrp.

> /usr/local isn't a normal subdirectory tree, as nothing should be
> shipped in it by Debian packages.
> 
> I had assumed that basefiles would do something like the following:
> 
> 1) if group staff has non-root users:
>   - ask if /usr/local should be writable by staff
> * yes: bail out; don't ask this question again
> * no: continue to 2

Please, no. I try not to mix "base-files" and "ask" in the same sentence.

Let's keep it simple: Beginning squeeze, base-files will no longer
create those directories with special permissions. I think this
respects the "principle of least surprise", as already created
directories (from lenny) will be kept in whatever status they are.

Note: Those directories are created only when base-files is first
installed by debootstrap from debian-installer.


If required, we can document that the default for squeeze has changed
in the release notes for squeeze.


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#538392: group staff: moving forward

[Santiago Vila]

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 "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#477990: Remove non-conflicting requirement in optional; relax dependencies

[Santiago Vila]

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
stem from a time where someone would actually want to install all of
optional.

As such, I suggest that this requirement be removed, and only the
meaning of optional "packages that you'd want without specialized
requirements" kept. The attached patch as an initiation point for
discussion acheives this.


While it made possible to install all of optional, the idea of this
policy was never that someone install all of optional. The idea was
that when browsing the package list, a user could actually choose
*whatever* set (small or big) of optional packages he/she wishes
without fear of conflicts.

I consider this to be a good property that we should keep (or maybe
achieve, in fact, I remember having posted an "override file for the
override file" at least once in the past). Therefore I object to this
proposal entirely.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#291460: Inclusion of Apache Software License versions in /usr/share/common-licenses

[Santiago Vila]

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
> > whether we should add the Apache 2.0 license to the list of
> > common-licenses?
> 
> Now that there have been several more seconds, I'm adding this patch to my
> repository for the next Policy upload.  Santiago, the Apache 2.0 license
> will be listed in common-licenses in the next version of Policy.  You can
> get a copy from, for example, the copyright file in the apache2.2-common
> package.

Noted, thanks.

Feel free to reassign/clone this bug to base-files if you like.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#458385: New version of Artistic License

[Santiago Vila]

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:
> 
> 
> 
> as "Artistic-2" in /usr/share/common-licenses/.

This should have been a bug against debian-policy, as explained in
base-files FAQ. Reassigning.

Thanks.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#436105: suggestion to add GPL-1 as a common licence

[Santiago Vila]

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 things like sed, joe, cvs, dict...
> 
>There are also countless packages that are under the GPL without
> mentioning the version at all (more than 2,000 but I was unable to get
> a precise number), they should therefore be considered "version 1 or
> above".
> 
>This is why I believe it wouldn't hurt to ship the GPL-1 with
> base-files, even if most people are going to use "any later version". It
> can be found here: http://www.gnu.org/licenses/old-licenses/gpl-1.0.txt

I delegate this decision to the policy group, as explained in base-files FAQ.

As your proposal does not require a change in debian-policy, you would
only need two seconds and no objections.

However, my personal opinion is that the GPL v1 should be considered
obsolete and we should deprecate it. The FSF would probably tell you
that the GPLv1 has bugs which have been fixed in GPLv2 and GPLv3.

We would be happier if we had less licenses to consider, not more.

Thanks.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#435476: base-files: add MIT License as a common license

[Santiago Vila]

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 delegate this decision to the debian-policy
group, as explained in the base-files FAQ, so I'm reassigning the report.

Thanks.

Bug#431109: [PROPOSAL] Disambiguate of Section 12.5, Deprecate GPL/LGPL symlinks

[Santiago Vila]

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 between "GPL version 2 or later" and "GPL
> >>> version 3 or later"?
> >
> >> If it says "version N or later", we should of course point to the
> >> *earliest* version to give users the choice which version they want.
> >
> > Wholeheartedly agreed.  I don't understand the rationale for doing
> > anything different.
>
> Same here.  My conclusion is that the GPL symlink should not be
> changed.  Policy can still deprecate the symlink, but the actual
> content should not be update for GPLv3.

Well, we can't pretend that "the GPL" is GPL-2 forever, so it
would be a bad idea to keep the GPL pointing to the old license.

The GPL is there for informative purposes only. Packages under GPLv2
or later will still be under GPLv2 or later, and the fact that we
say "the latest GPL is in /usr/share/common-licenses/GPL" in the copyright
file should not be interpreted as a relicensing. Moreover, the GPL-2
will still be there as far as it's a "common license".

What is clear is that packages under GPLv2 (without "or later") should
point to the GPL-2, not to the symlink. Packages not doing that are
already buggy and we should start fixing them.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#431109: [PROPOSAL] Disambiguate of Section 12.5, Deprecate GPL/LGPL symlinks

[Santiago Vila]

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,
> > + hence using the symlinks could lead to ambiguity.
> >
> > I disagree with this. It should be ok to point to the latest version
> > of the GPL if the program says "Version X or later". Many programs
> > do that, and we should not need to change them.
> 
> 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 between "GPL version 2 or later" and "GPL
> version 3 or later"?

We would not be necessarily relicensing to GPL version 3.

The paragraph "On Debian systems the GPL is in /usr/share/common-licenses"
is mainly for informational purposes. The license for the package
would still be the one in the source code, and it would be as well
the one in the copyright file.

In other words, I think it would be ok if our copyright files were worded
like this:

This program is free software. It is under GPL version 2 or later. On Debian
systems, the latest GPL version is in /usr/share/common-licenses/GPL.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#431109: [PROPOSAL] Disambiguate of Section 12.5, Deprecate GPL/LGPL symlinks

[Santiago Vila]

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 by the Free Software Foundation,
> > + hence using the symlinks could lead to ambiguity.
> > 
> > I disagree with this. It should be ok to point to the latest version
> > of the GPL if the program says "Version X or later". Many programs
> > do that, and we should not need to change them.
> > 
> > Instead, I think we should amend policy in this way:
> > 
> >   Packages under a fixed, definite version of the GPL should refer to
> >   the versioned GPL file in /usr/share/common-licenses.
> 
> Good idea.  Should we also specify that referring to the unversioned GPL
> is for programs that say "Version X or later" ?  I think this is not obvious.

Obvious or not, it is, IMHO, the logical thing to do. If it needs to
be written, so be it.

What we need is a policy which works when GPL is a symlink to the latest
available version and additionaly makes clear what people should do
in each case.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#431109: [PROPOSAL] Disambiguate of Section 12.5, Deprecate GPL/LGPL symlinks

[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,
+ hence using the symlinks could lead to ambiguity.

I disagree with this. It should be ok to point to the latest version
of the GPL if the program says "Version X or later". Many programs
do that, and we should not need to change them.

Instead, I think we should amend policy in this way:

  Packages under a fixed, definite version of the GPL should refer to
  the versioned GPL file in /usr/share/common-licenses.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#431109: [PROPOSAL] Disambiguate of Section 12.5, Deprecate GPL/LGPL symlinks

[Santiago Vila]

> 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 http://lists.debian.org/debian-legal/2007/06/msg00234.html)

Symlinks are not a problem. The real problem are hardcoded references
to "GPL" when they should have been references to GPL-2.

For programs which are under "GPL v2 or later" or "GPL v3 or later"
(most of them, if I'm not mistaken), the symlink is useful, so it
should be kept.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Launch of GNU GPLv3

[Santiago Vila]

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 common-licenses as soon as it is useful to
do so, but policy says:

   Packages distributed under the UCB BSD license, the Artistic license,
   the GNU GPL, and the GNU LGPL, should refer to the corresponding files
   under /usr/share/common-licenses,[82] rather than quoting them in the
   copyright file.

Am I right to think that policy refers to version 2 of the GPL, as such
paragraph was written before GPLv3?

Thanks.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#420701: debian-policy: GFDL is now in common-licenses

[Santiago Vila]

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" should be removed.

Please don't use such over-cautious language next time, as it delays
the final wording needlessly. Just state that the license is there, as
if it was already there, and everything else is just a bug in base-files.

If you are worried about "timing issues", we can do this:

1. Policy is officially ammended by the policy procedure, but a new
   debian-policy package is not uploaded yet.
2. A bug is submitted against base-files (or just somebody tells me about it).
3. The new base-files package having a new license is uploaded.
4. The new debian-policy package is uploaded afterwards.

Thanks.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#401173: base-file: include GFDL and more licences in /usr/share/common-licenses/

[Santiago Vila]

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  /usr/share/common-licenses/
> Artistic
> BSD
> GPL
> GPL-2
> LGPL
> LGPL-2
> LGPL-2.1
> 
> 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)
> 
> For more prospective candidates, see http://www.debian.org/legal/licenses/
> [ ... ]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#381729: Artistic licence

[Santiago Vila]

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 "foo" included in common-licenses" in
base-files FAQ.

Reassigning.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#348336: improve section on shared config files

[Santiago Vila]

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 a configuration file (e.g. bash and other
> > bourn compatible +shells share /etc/profile).
> >
> > You are implicitly saying that there are packages that "need" to modify
> > /etc/profile. 
> 
> The reason that /etc/profile is in base-files AFAICT is because it's shared 
> between all bourne-compatible shells. The above claims that /etc/profile is 
> an example of a shared configuration file. How is this inaccurate?

No, the above claims more than you say it claims. You are putting /etc/profile
as an example of a) file which is shared as a configuration file and
b) file which two or more packages need to be able to modify.

I object to b) being in policy. The file /etc/profile is not a file
which two or more packages need to be able to modify.

> [...]
> On the other hand there's currently at least 5 packages[1] that have a blurb 
> in their README saying something to the effect of "add this bit 
> to /etc/profile for the package to do everything it promises to". 
> No surprise to me that all of those happen to fit the single extra use case 
> that this proposal documents.
> -> So yes, there's a _demonstrated_ need for configuration packages to be
>able to modify /etc/profile

Not at all. Just because some packages do something does not mean they
need to do it, or that they need to do something the way they do it.

For example, let't take the user-es package, which you always mention
as an example of package that "needs" profile.d. What does such package do?

It has a README saying the user to add this line to /etc/profile:

if [ -f /etc/language-es ]; then source /etc/language-es; fi

The file /etc/language-es sets lot of environment variables. However,
/etc/profile is the wrong place to do that, as it does not work in every shell.
The file /etc/environment would be much more appropriate.

So, just because some packages tell the user "modify /etc/profile" does
not mean they "need" to modify /etc/profile.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#348336: improve section on shared config files

[Santiago Vila]

+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 that there are packages that "need" to modify
/etc/profile. The way I read policy 9.9, packages should not need
to modify /etc/profile to be useful.

Therefore I object to this proposal in its current form.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#299007: base-files: Insecure PATH

[Santiago Vila]

On Wed, 16 Mar 2005, Brendan O'Dea wrote:

> On Fri, Mar 11, 2005 at 01:39:28PM +0100, Santiago Vila wrote:
> >In this report, the submitter complains about /usr/local/bin being in
> >the PATH by default at the same time directories under /usr/local are
> >root:staff and world-writable. His complain is based on the existence
> >of become-any-group-but-root bugs.
> 
> Not world-writable.  Writable by group staff.
> 
> >If this is a bug at all, I think we should probably drop the root:staff
> >thing instead of changing the default PATH. So: Would anyone here
> >second the following patch, if it were a policy proposal?
> 
> Having /usr/local staff writable is *very* useful when using CPAN to
> install local packages w/- having to do the "make install" as root.
> 
> This is a benefit I'd prefer not to see removed, since the alternative
> generally involves giving sudo access to a subset of users...  which is
> in my experience tantamount to simply adding more entry points to
> gaining uid=0*, worse IMHO than having a subset of the filesystem
> writable to that same set of users.

That's not really the alternative. The alternative is doing it yourself
(i.e. chgrp -R staff /usr/local and so on) instead of it being the default.

This proposal is not to prevent people from having /usr/local group-writable
by staff, it's just a proposal to have "neutral permissions" in /usr/local.

If you are a perl hacker and like /usr/local to be group writable, you
will always be able to change the permissions yourself. The same is
true, of course, about putting /usr/local/bin in the PATH. The difference
is that you don't need to be a perl hacker to consider /usr/local/bin
in the PATH a useful thing (not to mention we already have a lot of perl
modules available via "apt-get install"). I bet that most people would add
/usr/local/bin to the PATH if it weren't the default, for private
shell scripts, perl scripts, python scripts, or whatever.


Should we count your mail as a formal objection? You know, it only
takes a negative vote to reject a policy proposal, even if it's
supported by a lot of people. I think this is going to be a real pity.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#299007: base-files: Insecure PATH

[Santiago Vila]

On Fri, 11 Mar 2005, Bill Allombert wrote:

> On Fri, Mar 11, 2005 at 01:39:28PM +0100, Santiago Vila wrote:
> > In this report, the submitter complains about /usr/local/bin being in
> > the PATH by default at the same time directories under /usr/local are
> > root:staff and world-writable. His complain is based on the existence
> > of become-any-group-but-root bugs.
> 
> Is there evidence of such bugs ? There is no binaries sgid staff in
> Debian to start with.

You don't need sgid staff binaries. Quoting the submitter:

 Become-any-user-but-root and become-any-group-but-root bugs are quite
 common. When a group of machines share user home directories via NFS
 exported from somewhere with default root-squash, getting root on one
 machine gives precisely that on all others of the group. There have been
 "genuine" such bugs also e.g. in sendmail [6].

The issue here is that "group staff" is equivalent to "user root", and
that we should better eliminate such equivalence from the default system.

> However, I disagree with the attitude of reassigning bug to
> debian-policy. If submitters want to make a policy proposal,
> they can propose it themselves.

Well, you have to be an official developer for that, so that's not
always possible.

In this case, you may consider this as a proposal made by me if you like.

This is not a bug in base-files because policy explicitly *mandates*
the root:staff thing, but as I see fewer and fewer people who find
the root:staff thing useful and more and more people who consider it
a potentially dangerous thing, I think that we would better drop the
staff thing from policy entirely, hence my reassign.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#299007: base-files: Insecure PATH

[Santiago Vila]

In this report, the submitter complains about /usr/local/bin being in
the PATH by default at the same time directories under /usr/local are
root:staff and world-writable. His complain is based on the existence
of become-any-group-but-root bugs.

If this is a bug at all, I think we should probably drop the root:staff
thing instead of changing the default PATH. So: Would anyone here
second the following patch, if it were a policy proposal?

diff -ru debian-policy-3.6.1.1.orig/policy.sgml 
debian-policy-3.6.1.1/policy.sgml
--- debian-policy-3.6.1.1.orig/policy.sgml  2004-06-25 23:11:36.0 
+0200
+++ debian-policy-3.6.1.1/policy.sgml   2005-03-11 13:25:27.0 +0100
@@ -5062,8 +5062,8 @@
 then
   if mkdir /usr/local/share/emacs 2>/dev/null
   then
-chown root:staff /usr/local/share/emacs
-chmod 2775 /usr/local/share/emacs
+chown root:root /usr/local/share/emacs
+chmod 755 /usr/local/share/emacs
   fi
 fi

@@ -5095,8 +5095,8 @@
  
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.
+   permissions 755 and be
+   owned by root:root.
  

 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: shell script sniplets in /usr/bin?

[Santiago Vila]

On Sun, 30 Jan 2005, Goswin von Brederlow wrote:

> Where do you want to put gettext.sh? Once in every gettext-base or
> only once in gettext-base-common?

I don't know, maybe in the same package as GNU.Gettext.dll :-)
(which is to say: first things first, before that there will be C# support)

Is there already an open policy proposal mandating multiarch?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: shell script sniplets in /usr/bin?

[Santiago Vila]

On Sun, 30 Jan 2005, sean finney wrote:

> think about the purpose path is supposed to serve.  the bash man page
> says PATH is "The search path for commands".  it mentions nothing of
> shell scripts to be included/sourced.

This is from bash(1):

. filename [arguments]
   source filename [arguments]

  Read and execute commands from filename in the current shell
  environment and return the exit status of the last command executed
  from filename.  If filename does not contain a slash, filenames in
  PATH are used to find the directory containing filename. The file
  searched for in PATH need not be executable.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#291631: cmp/diff/etc. lack PT_GNU_STACK header

[Santiago Vila]

On Mon, 24 Jan 2005, Bill Allombert wrote:

> On Mon, Jan 24, 2005 at 02:13:07PM +0100, Santiago Vila wrote:
> > 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 a lintian
> > > > warning exists is not polite.
> > >
> > > As far as I can see, this is the _only_ bug report by Greg Norris on the
> > > PT_GNU_STACK issue! How can it be a mass bug filling ?
> > 
> > Because many of the packages I maintain are also built on woody.
> 
> And how was the submitter supposed to know ? 
>
> Alternatively, is it sufficient that all your packages has the same
> problem to forbid people from reporting it ?

No, but it is sufficient that a problem is common to many packages to
have a lintian warning for it, before submitting bug reports.

I'll quote from the Debian FAQ:

[...] if you detect a bug in a package which is likely to appear in
other packages too, it might be better to get in contact with the
Lintian maintainers at [EMAIL PROTECTED] so that a new check is
written for Lintian instead of reporting the bug directly. This will
most likely prevent the bug to appear in future versions of the
package again, or in any other package of the distribution.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#291631: cmp/diff/etc. lack PT_GNU_STACK header

[Santiago Vila]

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 a lintian
> > warning exists is not polite.
> 
> As far as I can see, this is the _only_ bug report by Greg Norris on the
> PT_GNU_STACK issue! How can it be a mass bug filling ?

Well, just to clarify: I didn't mean to imply that he was mass bug
filing me with a single bug report, just that I could be mass bug filed
if the same criteria were used to submit similar bugs.

What I really meant is better expressed in the paragraph about lintian
I quoted from the Debian FAQ.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#291631: cmp/diff/etc. lack PT_GNU_STACK header

[Santiago Vila]

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 a lintian
> > warning exists is not polite.
>
> As far as I can see, this is the _only_ bug report by Greg Norris on the
> PT_GNU_STACK issue! How can it be a mass bug filling ?

Because many of the packages I maintain are also built on woody.

> Also, if you use woody to build your packages, you will use lintian
> woody, so whatever warning is added to sid lintian will not reach you.
>
> Given that, lintian warning checking for packages not built on sid is
> likely to be useless.

Not exactly. There are lintian reports available at lintian.debian.org.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#291631: cmp/diff/etc. lack PT_GNU_STACK header

[Santiago Vila]

On Mon, 24 Jan 2005, Jeroen van Wolffelaar wrote:

> On Mon, Jan 24, 2005 at 01:46:30AM +0100, Santiago Vila wrote:
> > That's the correct explanation, yes. It has never been a bug to build
> > a package using stable if the dependencies are compatible with the
> > ones in testing. In this case, Pre-Depends: libc6 (>= 2.2.4-4) is ok
> > because sarge has 2.3.2.ds1-20 and libc6 is not in oldlibs.
> 
> Well, it is recommended to build in sid, also, I do think building in
> woody is bad for several reasons:
> - you do not ship what's in sarge, you cannot reproduce the build
>   because it was build with software not in sarge. This is often the
>   case in minor ways, but intentionally doing so seems awkward at best.

I agree it's a little bit awkward, but the build is done on 10
different architectures. If there were a FTBFS problem, chances are
that I would be notified about it.

> - only one architecture will have these older woody depends, all other
>   architectures not. I don't know what reason you have to build on
>   woody, but that's defeated by this buildd reason.

If somebody using the i386 architecture (which is the most common one)
reports a bug and it's fixed in the package in sarge, I can point the
user to the URL of the fixed package, and he/she can install it
without having to upgrade libc6. I think this is definitely a good thing,
but I now agree that it might not compensate for the potential bad things.

> - Suppose one day after sarge is released a security update needs to be
>   made, and this package is suddenly build on sarge. There might be
>   weird bugs hiding there, since nobody tested it this way, only builded
>   on woody. I think it's very important to make sure security uploads
>   are not going to change the package in bad ways, and suddenly building
>   with a much different libc et al, and a different gcc with different
>   properties apparantly (this bug is directly caused by it) might be
>   resulting in such bad changes, we simply don't know, since it hasn't
>   been tested.

Yes, I understand that, and I mostly agree. Now please write a lintian
warning for PT_GNU_STACK. Mass bug filing me even before a lintian
warning exists is not polite.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#291631: cmp/diff/etc. lack PT_GNU_STACK header

[Santiago Vila]

On Mon, 24 Jan 2005 [EMAIL PROTECTED] wrote:

> I made a statistic on my machine:
> 1341 are '-' and 76 are '?' so less than 1% has the problem.
> 
> More importantly, there are all binaries that have been build a long
> time ago, with the exception of diffutils and rcs binaries.
> 
> Since diffutils was uploaded the 19/01/2005 I see no explanation why
> it has the problem unless the maintainer built it on top of woody.
> (The gcc changes is dated Sun,  9 Nov 2003).

That's the correct explanation, yes. It has never been a bug to build
a package using stable if the dependencies are compatible with the
ones in testing. In this case, Pre-Depends: libc6 (>= 2.2.4-4) is ok
because sarge has 2.3.2.ds1-20 and libc6 is not in oldlibs.

> > However, it could be that the lintian maintainer might be willing to add
> > a check for this, so I'm reassigning this to lintian as a wishlist.
> 
> Why not just rebuild diffutils on top of current sid and closing this
> bug ? This has always been the recommended practice.

The recommended practice has always been not to submit bug reports for
things that would result in a lot of bugs being filed. That is massive
bug filing, so it should be discussed first.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]