uld then be uploaded to
> experimental not before Monday or Tuesday next week, whenever that
> gets a slot by the release team. I hope that's not an issue?
I think it's unrealistic at this point to expect the uploads to start before
Monday of next week. Friday might actually be more re
sis of Build-Dependencies[1] also shows libpetsc3.4.2-dbg is affected,
which wasn't in your list.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
of today the spec still says "none". Who would have the authority to revert
> it back?
Reverted the no->none change.
Those changes that were not reverted, I regarded as reasonable text
clarifications that did not change the meaning of the spec. I overlooked
this particular incompatibi
e filed (since wanna-build is not
> currently in Debian)? does anyone have a simple testcase to see if the
> assertion in the comment about Dpkg::Deps is also true?
There is a buildd.debian.org virtual package in the BTS:
http://bugs.debian.org/buildd.debian.org
Cheers,
--
Steve Langasek
On Thu, Feb 20, 2014 at 12:31:28PM +, Colin Watson wrote:
> On Wed, Feb 19, 2014 at 02:29:45PM -0800, Steve Langasek wrote:
> > Ok. The statistics still seem awfully low to me; but I guess
> > http://people.debian.org/~cjwatson/dhstats.png shows there hasn't actually
>
org/~cjwatson/dhstats.png shows there hasn't actually
been a huge uptick in dh(1) adoption over the past year, as a percentage of
all packages. Maybe it's time for a MBF on non-dh packages. ;-)
--
Steve Langasek Give me a lever long enough and a Free OS
Debia
es-missing-required-target[1],
> which is on ftp-masters' auto-reject list.
> I attached dd-list of packages that were is non-successful state in
> the "buildarch" rebuild. Packages marked with "*" were also in
> non-successful state in the "current&quo
Control: reassign -1 dpkg
Control: tags -1 patch
On Mon, Jul 15, 2013 at 03:23:30PM -0700, Steve Langasek wrote:
> > I might perhaps consider looking into reviewing and applying tested
> > patches if someone wanted to provide them, but that's not a thrilling
> > prospect ei
On Mon, Jul 15, 2013 at 10:00:16PM +0200, Guillem Jover wrote:
> On Mon, 2013-07-15 at 12:32:04 -0700, Steve Langasek wrote:
> > Dpkg maintainers, could you please have a look at this? I'm not sure if
> > this is a dpkg-maintscript-helper bug, or expected behavior that will
&
t.d/stop-bootlogd 2.88dsf-42 initscripts
In the maintainer scripts, this translates into rules such as:
dpkg-maintscript-helper rm_conffile /etc/init.d/bootlogd 2.88dsf-42
initscripts -- "$@"
I would expect dpkg-maintscript-helper to know that these conffiles are no
longer owned by the initscri
1
Er, read the version number. This is trying to configure the *stable*
version of the lmodern package. This has nothing to do with
dpkg-maintscript-helper, which is only applied in the *testing* version of
the package.
--
Steve Langasek Give me a lever lo
symlink to /mnt/usr, the
symlink traversal will go wrong; so an absolute symlink is needed.
Nowadays this is less relevant, but I'm not sure the remaining problems with
it warrant a change to policy. (But there *are* problems - most
particularly, when unpacking in a directory other than the
istics very similar to our native one so that the
same flags can be used everywhere. Choice #3, putting effort into a design
to allow passing separate flags to the native and cross compilers, is a
fairly unpalatable workaround.
--
Steve Langasek Give
On Sat, Jun 23, 2012 at 11:51:28PM +0200, Guillem Jover wrote:
> On Sat, 2012-06-23 at 13:54:33 -0700, Steve Langasek wrote:
> > On Sat, Jun 23, 2012 at 01:54:18PM +0200, Guillem Jover wrote:
> > > W/o having checked this at all, my first assumption is that this is
> >
er have been
created in Ubuntu dpkg by a package other than the one dpkg considered
native at the time, and if there has been a cross-grade we have no record of
that anyway; so we should fix this up in all cases by marking this as
native.
--
Steve Langasek Give me a lever
for M-A: none packages, since an M-A: allowed package is always treated as
either M-A: foreign or M-A: none. And even for an M-A: foreign package,
there might be special circumstances where you want to specify the
architecture, such as when creating a metapackage of some kind.
Cheers,
--
Steve Lang
ot;. The difference is that now, dpkg knows not only
that the package is of the wrong architecture but that its dependencies are
not satisfied.
So to get the previous behavior, you need --force-architecture
--force-depends.
Though hopefully, you will shortly not need to --force at all and will be
able
On Wed, Feb 08, 2012 at 04:55:02PM -0800, Russ Allbery wrote:
> Steve Langasek writes:
>
> > The unfounded assumption here is that you will always install a
> > foreign-arch M-A: same package together with the native-arch version.
> > If I install libaudio2:i386 becau
e on my
system uses libaudio2, I still expect to get /usr/share/libaudio2/AuErrorDB
installed.
In general, anything that introduces assymetric handling between native and
foreign arch packages at the dpkg level is probably going to be a bad idea.
--
Steve Langasek Give me a lev
the amd64 and i386 version of a package will
> want the same flags, so we really need some way of having a
> multiarch-aware verson of the -config script.
Preferably by s/foo/pkg/. pkgconfig gets this right, the standalone tools
all get it wrong, there's no good reason not to just replace the
en apt will not be able to
> nicely present the package to the user before the user has installed
> it. Hope this clarifies.
Oh, ok. I had understood "the rest of the architectures" rather than "the
rest of the packages" - thanks for the clarification.
> the libc package is that's a chicken and egg situation.
What libc support do you mean? All per-architecture executables should have
dependencies on the libc package for their arch anyway, so I don't see how
libc support really enters into this.
--
Steve Langasek
greed)
Any reason not to ship it as /usr/share/doc/$pkg/changelog.$arch? (I.e., I
think /usr/share/doc is still the right place for it, even if it can't be
changelog.Debian.gz anymore.)
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
've suggested complementing DEB_BUILD_OPTIONS with
DEB_BUILD_MAINT_OPTIONS, it stands to reason that we might define some
macros for common cases.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I
fault.mk
> ---
For the record, I'll repeat here the view expressed at the meeting (which I
recall being shared by Bdale and Ian): I don't think dpkg should be exposing
such an interface at all. We don't want to encourage the use of makefile
includes for such things.
--
Steve Langa
d flags.
> QUESTION: Is this ok to assume that all build flags can be "delimited"
> by a space character?
Counterexample: -Wl,-z -Wl,defs
While this *can* also be written as -Wl,-z,defs, I'm not sure there's any
way to guarantee it will be?
--
Steve Langasek
iverts foo to foo.distrib and wraps
it; another package diverts foo.distrib to foo.distrib.distrib and wraps it
again), but having two diversions happen in parallel, where the unpack order
determines which package ends up on top, isn't useful at all.
--
Steve Langasek
pend,
> not a depend, shouldn't it?
Absolutely not.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slang
h an RFC2822-style file, it's straightforward to make
this optional with a sensible fallback. dpkg-divert already has a built-in
default (according to the manpage) of .distrib; that's probably
reasonable to use here.
--
Steve Langasek Give me a lever l
> > "file.divert-$package".
> >> What about moving a diversion from package A to B?
> > That's why we have "Conflicts" to ensure a package is removed before the
> > other is installed.
> But we only need breaks+replaces there.
In theory
n support.
> gcc-4.5 seem to build fine.
Your mail doesn't seem to have made it through to the Debian mailing lists,
and it arrived at the linaro list with the attachments stripped (presumably
for size). :( Can you post these logs on a website somewhere?
--
Steve Langasek Gi
Hi guys,
Another patch for multiarch support. The need for this was discovered when
trying to bootstrap a cross-toolchain against a multiarchified
eglibc-source.
We should explicitly prepend the appropriate multiarch paths to our library
search path. These would be picked up later on anyway i
iff --git a/debian/changelog b/debian/changelog
index 9f23d32..5cbb06f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -103,6 +103,11 @@ dpkg (1.16.0) UNRELEASED; urgency=low
[ Updated dselect translations ]
* Spanish (Javier Fernandez-Sanguino).
+ [ Steve Langasek ]
+ * add new var
On Wed, Mar 09, 2011 at 03:47:00AM +0100, Guillem Jover wrote:
> On Tue, 2011-03-08 at 15:11:10 -0800, Steve Langasek wrote:
> > Add new variables that return the "ideal" GNU triplet for each architecture
> > which should be used as the path component for library instal
elog
index 9f23d32..5cbb06f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -103,6 +103,11 @@ dpkg (1.16.0) UNRELEASED; urgency=low
[ Updated dselect translations ]
* Spanish (Javier Fernandez-Sanguino).
+ [ Steve Langasek ]
+ * add new variables, DEB_HOST_MULTIARCH and DEB_BUILD
elog
index 9f23d32..5cbb06f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -103,6 +103,11 @@ dpkg (1.16.0) UNRELEASED; urgency=low
[ Updated dselect translations ]
* Spanish (Javier Fernandez-Sanguino).
+ [ Steve Langasek ]
+ * add new variables, DEB_HOST_MULTIARCH and DEB_BUILD
On Tue, Mar 08, 2011 at 04:57:13PM -0600, Jonathan Nieder wrote:
> Steve Langasek wrote:
> > Add new variables that return the "ideal" GNU triplet for each architecture
> > which should be used as the path component for library installation.
> Neat! I like it (FWIW
Oh; that last mail probably didn't make any sense at all because I managed
to miss including multiarchtable in the patch altogether. This should be
better. :)
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.deb
rgency=low
[ Updated dselect translations ]
* Spanish (Javier Fernandez-Sanguino).
+ [ Steve Langasek ]
+ * add new variables, DEB_HOST_MULTIARCH and DEB_BUILD_MULTIARCH, that
+return the "ideal" GNU triplet for each architecture which should be
+used as the path component for
Oops, sorry, previous version of the patch has the Ubuntu GNU triplet in
the table instead of the Debian one; amended.
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/
rgency=low
[ Updated dselect translations ]
* Spanish (Javier Fernandez-Sanguino).
+ [ Steve Langasek ]
+ * add new variables, DEB_HOST_MULTIARCH and DEB_BUILD_MULTIARCH, that
+return the "ideal" GNU triplet for each architecture which should be
+used as the path component for
On Mon, Mar 07, 2011 at 01:53:22AM -0500, Anders Kaseorg wrote:
> On Sat, 5 Mar 2011, Steve Langasek wrote:
> > For packages in wheezy/sid, it's redundant because the versioned dependency
> > is already satisfied by the version of dpkg in squeeze, i.e., it's met even
>
version of dpkg in squeeze, i.e., it's met even
before upgrading to wheezy or sid. So in this case the pre-dependency
should *not* be set, as it only serves to complicate the upgrade path.
HTH,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian D
Mentor: Steve Langasek; supported by Raphaël Hertzog for dpkg maintainer
review and sign-off
Summary: implement support for declarative diversions in dpkg, to obsolete
manual calls to dpkg-divert in maintainer scripts
Required skills:
* C programming
* ability to communicate clearly in
d in the directory
for the native architecture... which means in a cross-grade where the native
architecture changes, dpkg will suddenly lose sight of all the native
packages, now treating them as packages for the new "foreign" arch when they
should be packages for the new "native&quo
On Tue, Mar 01, 2011 at 05:11:05PM -0600, Jonathan Nieder wrote:
> Hi Steve,
> Steve Langasek wrote:
> > --- a/src/help.c
> > +++ b/src/help.c
> > @@ -186,6 +186,11 @@ preexecscript(struct command *cmd)
> >size_t instdirl;
> >
> >if (*instdi
Fix up the DPKG_ADMINDIR env var being passed to maintainer scripts when
running with --root; we need to prune the root directory name from the front
of the admindir we set for chrooted processes, otherwise the directory won't
be found.
---
src/help.c |5 +
1 files changed, 5 insertions(+)
that actually still needs to be
fixed, not one that has been tagged 'pending'.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
On Mon, Feb 21, 2011 at 09:43:41AM +0100, Guillem Jover wrote:
> On Sun, 2011-02-20 at 23:38:36 -0800, Steve Langasek wrote:
> > On Mon, Feb 21, 2011 at 07:32:19AM +0100, Guillem Jover wrote:
> > > Given the above we'd need to either switch to i586-linux-gnu or
> > >
tion in those packages is buggy, per above.
Yep, software is buggy. We should be careful not to design a system that
fails because it requires software to not be buggy. :)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
t takes longer. (Multiarch in
> general is an example of this).
I don't see either of these to be technically better or worse. The fact is
that we are going to *have* to document multiple points where our directory
strings do not follow naturally from the existing array of GNU triplets; and
tha
k.
Since that doesn't require dpkg to look beyond one level of dependencies
when calculating, I would be ok with that as a middle ground, if the dpkg
and apt maintainers agree. Though I suspect the cases where this matters
will be few in practice.
--
Ste
have only
> foo_1.0_foreign installed. Should foo_2.0_all Multi-Arch:foreign be
> considered an upgrade? I think so.
For purposes of simplicity of the dpkg implementation, I think it shouldn't.
A robust, consistent, comprehensible dpkg implementation is more important
than transpar
lease. If we can (collectively) get our decision made on
the path selection *now*, that's achievable - and we can be rid of ia32-libs
from Debian (unstable) and Ubuntu within a year, and we can bring armhf up
as the first multiarch-from-the-start port in Debian. If we instead
g to
upgrade foo_1.0_all to foo_2.0_foreign, but *nobody would understand what
dpkg was doing*, and why this case was different than the others. :)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the w
the
conflict and allowing foo_2.0_all to be configured.
So yeah, that seems ok to me, but I guess you're not convinced or you
wouldn't have asked. :) What other way do you see this working? Should
dpkg auto-remove multiarch packages when an upgrade to _all is requested?
That seems
would like to see this
> better addressed in Linaro and/or upstream.
I'm not sure how Linaro could better address this, short of persuading
upstream to allocate a separate triplet for armhf - which has been
explicitly refused on the upstream mailing list. Do you have something else
in
ta
in the long term - which is why the (right) goal is to merge the armhf work
into Debian so that there *isn't* a delta.
Bitbake doesn't help with that goal; the only way to help that goal is to
have the sometimes-difficult conversations with the Debian maintainers that
let us arrive
for discussion in Debian? Should I bring this up on the
debian-embedded list? Are there other stakeholders who would have input
regarding the array of available uclibc ABIs and how to specify these?
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
De
kg. By smashing these to :native instead of :same, we have
enough information to decide *locally* whether a given package's
dependencies are satisfied. Robust, efficient, and avoids getting hung up
on hypothetical corner cases.
--
Steve Langasek Give me a lever long enough
On Thu, Feb 10, 2011 at 05:00:13PM +0100, Raphael Hertzog wrote:
> Steve reported me this problem concerning the current implementation of
> the multiarch spec (he uses my latest pu/multiarch/snapshot/* branch).
> Le mercredi 09 févr. 2011, Steve Langasek a écrit :
> > - I'v
On Thu, Dec 23, 2010 at 05:34:28PM -0800, Steve Langasek wrote:
> Output pkg:arch in dpkg -l output for non-native packages, and parse pkg:arch
> syntax in input arguments to dpkg -l
> ---
> src/query.c | 29 +++--
> 1 files changed, 27 insertions(
On Thu, Dec 23, 2010 at 05:33:41PM -0800, Steve Langasek wrote:
> ---
> src/query.c |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
Sorry, thought I was working on an up-to-date branch and apparently wasn't.
(Also apparently am an expert in shooting myself in
*** BLURB HERE ***
Steve Langasek (2):
Output pkg:arch in dpkg -S output for non-native packages
pkg:arch handling for dpkg -l
src/query.c | 36 ++--
1 files changed, 34 insertions(+), 2 deletions(-)
>From 0404e9789b26c9e4caff1f409920925f46ea9cf6 Mon
*** BLURB HERE ***
Steve Langasek (2):
Output pkg:arch in dpkg -S output for non-native packages
pkg:arch handling for dpkg -l
src/query.c | 36 ++--
1 files changed, 34 insertions(+), 2 deletions(-)
>From 0404e9789b26c9e4caff1f409920925f46ea9cf6 Mon
bian.org>
as a prerequisite.
Steve Langasek (2):
Output pkg:arch in dpkg -S output for non-native packages
pkg:arch handling for dpkg -l
src/query.c | 36 ++--
1 files changed, 34 insertions(+), 2 deletions(-)
--
Steve Langasek Give
Output pkg:arch in dpkg -l output for non-native packages, and parse pkg:arch
syntax in input arguments to dpkg -l
---
src/query.c | 29 +++--
1 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/src/query.c b/src/query.c
index 552f56e..50b5e9e 100644
--- a/src
---
src/query.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/src/query.c b/src/query.c
index 68244ac..552f56e 100644
--- a/src/query.c
+++ b/src/query.c
@@ -215,6 +215,13 @@ static int searchoutput(struct filenamenode *namenode) {
for (i=0; i < PERFILEPACKAGE
y.
So even if you persuaded the upstream toolchain folks to specify a new
triplet for armhf after all, I think we should still go ahead with a
separate name mapping table for multiarch.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
On Mon, Aug 16, 2010 at 01:36:16PM -0400, Ёёёё!ёё wrote:
> debian и dpkg жили, живут и будут жить.
(Idiomatic) translation: long live debian and dpkg.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can m
, but the depended-on package is
> more likely to be available if the package declares a
> dependency (particularly for postrm remove).
> The postrm script must cleanly skip actions
> that require a dependency if that dependency isn
)
Do you have an example of using Suggests: in this way that *shouldn't* be
converted to a trigger instead?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
e the outcome is incorrect.
It'll always be possible to end up with such a sequence as a result of
manual action on the part of the user, but I think we should do our best to
avoid landing a user in this situation automatically. Having foo Depends:
ucf, and ensur
ally replaced; and for diversions handling, you don't want to
automatically assume a diversion is meant for each file collision.
Declarative diversions are long overdue; but I see no value in conflating
them with Replaces like this.
--
Steve Langasek Give me a lever long eno
he package dependencies will be at least
> + unpacked or "Half-Installed".
> +
>
I disagree with this change. If you are making use of non-essential
packages in your postrm, you *should* use the Depends: field; you just
*also* have to have a cle
7;broken', which it seems
we're trying to do even though we use the common English verbs throughout
Policy for the other relationship fields; and avoids the ambiguous "is
unpacked" where what we really mean is the much more bulky "is in an
unpacked state". The whole thing c
On Mon, Jul 19, 2010 at 07:02:32PM +0100, Hector Oron wrote:
> 2010/7/18 Steve Langasek :
> > I'm puzzled why dpkg needs a unique triplet for a port. dpkg needs to map
> > port names to triplets, but why does it need to do the inverse? And if it
> > doesn't need
ss it’s not a
> big deal in practice. I’ll prepare an upload fixing xz-utils tomorrow
> morning.
That's not a fix, and not appropriate to upload without consulting
debian-devel.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
hat is a disadvantage, but following the advantages, the security
> part is acceptable.
It sounds like you are saying that it's acceptable to compromise security in
order to make it easier for end users to install software.
Over my dead body.
--
Steve Langasek Give me a lev
," bad architecture, returning %d",thisf);
+ (*interestingwarnings)++;
+ return thisf;
+}
if (possdependee->status == stat_installed ||
possdependee->status == stat_triggerspending) {
debug(dbg_depcondetail," is installed, ok and found&quo
;
my $changelogfile = 'debian/changelog';
--
1.6.3.3
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
$self = shift;
my $res = $self->{package};
+if (defined($self->{arch})) {
+ $res .= ":" . $self->{arch};
+}
if (defined($self->{relation})) {
$res .= " (" . $self->{relation} . " " . $self->{version} . &q
;
+ if (fc_depends || fc_dependsversion) thisf= (dependtry >= 3) ? 2 : 1;
+ debug(dbg_depcondetail," bad architecture, returning %d",thisf);
+ (*interestingwarnings)++;
+ return thisf;
+}
if (possdependee->status == stat_installed ||
po
if (!isalnum(c) && c != '-')
+ break;
+ if (!c)
+return NULL;
+ if (isspace(c) && ep) {
+while (isspace(*p))
+ p++;
+*ep= p;
+return NULL;
+ }
+ snprintf(buf, sizeof(buf), _(
+ "character `%c' not allowed (only letters, digits
Hi folks,
Here's a set of 4 patches to get the resolver side of multiarch
implemented; including two patches to dpkg-dev so that I can actually use
dpkg-gencontrol to create test packages. :)
Steve Langasek (4):
Allow pkg:arch syntax in package relationship fields
Implement archite
On Sat, Aug 29, 2009 at 01:31:17PM -0700, Steve Langasek wrote:
> On Sat, Aug 29, 2009 at 01:29:47PM -0700, Steve Langasek wrote:
> > The rest are included in the attached revised patch.
> > > And do not call it yet, I'd like to add that part only later on once
> > &
On Sat, Aug 29, 2009 at 01:29:47PM -0700, Steve Langasek wrote:
> The rest are included in the attached revised patch.
> > And do not call it yet, I'd like to add that part only later on once
> > it's safe to install foreign architecture packages. Or rather, split it
&g
the end of the branch.
Right, done - also attached as a separate patch.
> And thinking about it maybe add a warning on --foreign-architecture
> stating it's currently a no-op.
Opted not to do this at the moment, focusing on making it a non-no-op soon
instead...
--
Steve Langasek
ture *archp;
+int archok = 0;
+
+for (archp = foreign_archs; archp; archp = archp->next) {
+ if (!strcmp(pkg->available.architecture,archp->arch)) {
+archok = 1;
+break;
+ }
+}
+if (!archok)
+ forcibleerr(fc_architecture,
+ _(
e and in the
> debian directory
> will have a directory named , and i can add a new file in this
> directory.
This mailing list is for the development of the dpkg package manager. I
suggest you direct your questions to the debian-mentors mailing list.
--
Steve Langasek
to be handled
right for the sanity of our users.
> Another option would be for foo to
> Provides: foo-$(DEB_HOST_GNU_TYPE)-${binary:version}
> and for foo-dbg to depend on that. Or for plugins
> Provides: foo-$(DEB_HOST_GNU_TYPE)-$(PLUGIN_ABI).
I don't think that's acceptable.
--
St
need to be a way to merge architecture
declarations from multiple files, to allow individual packages to ship
conffiles enabling a corresponding arch.
> Migrating ia32-libs, ia32-libs-gtk and amd64-libs will be tricky if
> not impossible to automate. The release notes might have to say that
ing an optional diversion target - or at least for not using
".diverted" by default, since we wouldn't want diversions from multiple
packages to collide. Maybe ".diverted-$package", then?
--
Steve Langasek Give me a lever long enough and a Free OS
On Mon, Jun 23, 2008 at 12:49:08AM +0200, Goswin von Brederlow wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
> >> FIXME: what if a line changes? Only allow certain changes?
> > ... that's a rather large FIXME. Without fixing this, such an
> > implementat
anaged during a normal postinst/prerm stage,
and there are definitely cases when update-alternatives from a maintainer
script is still the only correct way to handle some alternatives. These
two proposals should be handled separately.
--
Steve Langasek Give me a lever long enoug
is that it must
preserve user changes, not that it preserve config files completely
unmodified.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu D
ded settings provided by the package, it doesn't
mean timestamps will somehow be preserved.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
On Sat, Mar 29, 2008 at 08:38:58PM +0100, Pierre Habouzit wrote:
> On Sat, Mar 29, 2008 at 01:18:51AM +0000, Steve Langasek wrote:
> > On Fri, Mar 28, 2008 at 10:42:58AM +0100, Pierre Habouzit wrote:
> > > On Fri, Mar 28, 2008 at 09:03:07AM +, Raphael Hertzog wrote:
> >
he glibc sometimes does, as it guards its vital parts using internal
> symbols only when needed).
Well, if the glibc test suite were in good enough shape to be used as input
for package build success/failure, that would be caught at build time too...
Cheers,
--
Steve Langasek
ds.
And why is that dpkg's business to try to fix? If the maintainer has
changed the order of dependencies in the source package, they have some
reason for doing so.
Neither of these are very good reasons for wresting control of the Depends:
field from the maintainer.
--
Steve Langasek
1 - 100 of 129 matches
Mail list logo
