a
simple dependency on B, then (absent any Pre-Depends) the priority of B is
not relevant any more and thus doesn't need to be overridden.
And what about the dependencies of B? Is it allowed to have non-simple
dependencies in your suggestion?
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383
it.
At least I'd suggest to not allow it in the Debian archive yet. Not
everything dpkg supports must be allowed by policy. (Like upper case
letters in package names).
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debian-policy-requ
like a any-FOO matching any debian architecture *-FOO and
FOO would be something simple.
Having magic like any-arm also matching armhf means it cannot be
processed without having special knowledge of the architectures.
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
describes absolutely nothing currently, and having such important fields
a meaning that you cannot calculate without knowing what architectures
the system finally using the package uses makes it unhandable).
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
. The
menu program could just read .desktop files and generate a menu for the
window managers using the already existing menu-methods.
The format is not really the problem. The problem is the missing
contents of desktop files.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-policy
to their
users by not having a .desktop entry, Gnome programs can have their
OnlyShowIn=Gnome so no other newfangled DEs sees them but with
a menu entry users of classical window managers could still start
them and so on.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-policy
* Josselin Mouette j...@debian.org [130512 12:55]:
Le dimanche 12 mai 2013 à 12:36 +0200, Bernhard R. Link a écrit :
Some points for a having menu files:
- it is supposed to include all programs, and does
not do choices like you don't want that program
In my opinion, this is an anti
.
Bernhard R. Link
--
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/2012093545.ga1...@client.brlink.eu
for cvs -d (i.e. usually starting with :pserver:),
followed by an optional module name (seperated by a space).
I think it might also make sense to explicitly request that the fields should
describe an anonymous checkout.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-policy-requ
* Bernhard R. Link brl...@debian.org [120108 14:03]:
* Russ Allbery r...@debian.org [120107 20:42]:
Bernhard R. Link brl...@debian.org writes:
Something that was only added to git after that discussion was already
running for a while is git-clone's -b. Sadly
Vcs-Git: git
all those bugs again, like it was
done before versioned closes where introduced).
Bernhard R. Link
--
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
unusual corner cases.
Only stylistics: How about not using flawed? Something like
Also the way library SONAMEs are represented in fileshlibsfile
files makes it difficult to use them in some unusual corner cases.?
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-policy-requ
that.
Bernhard R. Link
--
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/20120227193203.ga1...@server.brlink.eu
* Russ Allbery r...@debian.org [120107 20:42]:
Bernhard R. Link brl...@debian.org writes:
Something that was only added to git after that discussion was already
running for a while is git-clone's -b. Sadly
Vcs-Git: git://git.eyrie.org/kerberos/webauth.git -b squeeze
does not work
* Russ Allbery r...@debian.org [120107 17:51]:
I wonder if something like
Vcs-Git: git://git.eyrie.org/kerberos/webauth.git squeeze
could be made to work.
My understanding was that the debcheckout developers were not enthused
about adding a syntax that Git upstream didn't support,
* Russ Allbery r...@debian.org [111026 19:12]:
Bernhard R. Link brl...@debian.org writes:
* Russ Allbery r...@debian.org [111026 00:43]:
I think it would be lovely to just use RFC 2119 language or a close
adaptation thereof. We're sort of reinventing the wheel here,
There is also those
* Julian Gilbey jul...@d-and-j.net [111027 12:09]:
3.2: Unchanged,
So a package without a version is fine?
except in final paragraph where should be converted
is changed to SHOULD be converted.
So you suggest to change policy so that this is no longer a bug if not
done?
Bernhard R
difference. Having to have some all-upercase MUST
in every second sentence is not only ugly but would not improve policy
at all.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
/copyright.
And not be mislead to think everything is fine just because we thought
it is and thought it would be a clever idea to hide any discrepancies
away.
Bernhard R. Link
[1] Exceptions are usually removal of indendation/comment characters/
line splitting, deduplication and things like
for the existence of the target *reliably*,
then we don't need to enforce its presence at all.
Lintian checks do not need to be as reliable. (Reliable tests are
better, but hardly any lintian check is as reliable to an extent people
seem to require for a build time build-arch check.)
Bernhard R
versions.
Gtk simply is not a good example for any sane library handling, as it
insists of inventing it's own way for everything. (Just think of the
inlining of other libraries' functions so one never can know that
libraries are actually used).
Bernhard R. Link
--
To UNSUBSCRIBE, email
if it also could
include the Architecture: of those packages. That would make it easier
for things like reprepro to decide if there might be some binary package
missing. (Or for other forms of poor-man's stateless wanna-build stuff).
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-policy
or not).
I'd rather see this as fields only there if the upload has something to
say in this regard.
Bernhard R. Link
[1] Which is something I'm very happy if it changes[2]. Though having it as
Package-List:\n src:srcname is a bit more complicated than just
having Section and Priority
(and nothing
making those rules phony, as commonly misused patch rules often do),
this problem can be worked around. But that does not help if upstream's
build system does not behave well.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject
way to pass CFLAGS to configure is as a command line argument,
not an env var.
That's only available since 1999-10-31 [1], so while it is clearly is
the preferred and better way, some tools tend to give them as environment
variables.
Bernhard R. Link
[1]
http://git.savannah.gnu.org
and there will definitly be code that has
problems because there is simply no way to test all those different
cases.
Bernhard R. Link
--
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
).
How about rather stating that the maintainer should order the list so
that the first choice so that a user is commonly best advised to chose
the earlier over later choices? (With some extra bla about buildd
behaviour).
Bernhard R. Link
--
Never contain programs so few bugs, as when
.
The difference between optional and extra is indeed mood today. But I
guess that is mostly because dh_make is making everything optional
instead of extra by default...
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble
in our archive).
Hochachtungsvoll,
Bernhard R. Link
[1] It got a bit better, but still has that feature available by a
flag and does not warn enough against its usage in my eyes.
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble
, as when
the symbols file is updated, the shlibs may not be bumped.
Perhaps creating shlibs files out of symbols files at build time could
also be a solution for this.
Hochachtungsvoll,
Bernhard R. Link
--
Never contain programs so few bugs, as when no debugging tools are available
be nothing left and especially when I reinstall it everything
should be as after the first installation.
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
of different dependencies per architecture,
which cannot yet be expressed in an architecture all package.
Hochachtungsvoll,
Bernhard R. Link
--
Never contain programs so few bugs, as when no debugging tools are available!
Niklaus Wirth
--
To UNSUBSCRIBE, email to debian-policy-requ
, standard quilt patching done at build time
or
this package may do something special but noone has yet looked at it.
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas
being so ridiculous as I am?
Thanks in advance,
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
| grep \/64
|lrwxrwxrwx root/root 0 2005-01-07 17:49 ./usr/lib/64 - ../lib64
|lrwxrwxrwx root/root 0 2005-01-07 17:49 ./lib/64 - ../lib64
I can guess you can imagine what happend when upgrading in half of the cases...
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE
or next but one release again.
Hochachtungsvoll,
Bernhard R. Link
--
Never contain programs so few bugs, as when no debugging tools are available!
Niklaus Wirth
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
R. Link
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
that this is no longer needed within Debian, but I think it is
still a usefull feature and use it a lot in local repositories, so would
like to have changes handling tools continue to support it.
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
are duplicated by a
.desktop file.
Hochachtungsvoll,
Bernhard R. Link
--
Never contain programs so few bugs, as when no debugging tools are available!
Niklaus Wirth
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
splitting it into a mkfs*/fsck* part (which needs the libuuid1
dependency which again pulls in passwd, which again pulls in more stuff)
in an extra package seems a more sensible choice if things were to change
in a way to allow more minimal build chroots).
Hochachtungsvoll,
Bernhard R
this mean you have nothing
against debian-policy stating colons are not allowed (and how they
should be translated) in upstream versions, as long dpkg can still
cope with them for non-Debian packages?
Hochachtungsvoll,
Bernhard R. Link
--
The man who trades freedom for security does
and such things...
Hochachtungsvoll,
Bernhard R. Link
--
The man who trades freedom for security does not deserve
nor will he ever receive either. (Benjamin Franklin)
agsinst debian-policy, if
noone contradicts.
Hochachtungsvoll,
Bernhard R. Link
--
The man who trades freedom for security does not deserve
nor will he ever receive either. (Benjamin Franklin)
pgpKArjium9XK.pgp
Description: PGP signature
, if there is
only *one* programm or *one* icon with too much colours.
Hochachtungsvoll,
Bernhard R. Link
it is not a conffile. (And a Sentence in policy
that this file has to)
Hochachtungsvoll,
Bernhard R. Link
45 matches
Mail list logo
