m saying is that if package A is Important / Required and has 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
he rest in via dependencies is
likely to not run into any ugly problems. So simple algorithms have
a chance.
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe".
out-of-archive packaging and
> infrastructure, etc. So I'm not sure this seems appealing… but I'll
> make a note of at least checking 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
hat already knows those architectures.).
Something 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 architect
Really? This is far too complicated for most programs to implement
properly. I'd suggest to rather fix dpkg (and also fix policy. The footnote
describes absolutely nothing currently, and having such important fields
a meaning that you cannot calculate without knowing what architectures
the system fi
ould 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-requ...@lists.debian.o
* Josselin Mouette [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 progra
oking programs are not exposed 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 UNSUB
much point in arguing about it.)
Didn't the GR spoke about the "The initial policy" exactly to make sure
such a purely technical change like this does not need another GR?
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject
lts in a working dir aquivalent
for all practical purposes to one where build and binary never ran.
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
fields?
cvs: a identifier suiteable 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 UN
* Bernhard R. Link [120108 14:03]:
> * Russ Allbery [120107 20:42]:
> > "Bernhard R. Link" writes:
> > > Something that was only added to git after that discussion was already
> > > running for a while is git-clone's -b. Sadly
> >
> >
need to close 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://li
ses.
Only stylistics: How about not using "flawed"? Something like
"Also the way library SONAMEs are represented in shlibs
files makes it difficult to use them in some unusual corner cases."?
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-policy-requ...@l
by FHS or mentioned by Debian policy, is that
a violation? If a package fails to work with home directories in /user
or a package fails to work with TMPDIR=/tempshares/username, is that
a bug in the package?
The answers to all those questions should be obvious, but as people like
to make policy more e
* Russ Allbery [120107 20:42]:
> "Bernhard R. Link" 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
&g
* Russ Allbery [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, but I
* Julian Gilbey [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
do
* Russ Allbery [111026 19:12]:
> "Bernhard R. Link" writes:
> > * Russ Allbery [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,
>
>
not only
some little wording 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 "uns
so they should be able
to make an informed decision from looking at debian/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 o
check as with all the
> rest - if we can actually check 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 peop
jority of quiet build logs comes from cmake based systems and (newer)
I think cmake has the additional problem that it misses a proper middle
ground, without verbosity it is says not nearly enough, with verbosity
it gives quite more output than a classic automake like build system.
Bernhard R
me program using different
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
ds appearing depending on
> whether a source is uploaded 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
"
ey have not
> yet seen).
If it really is in the .dsc files then it would be nice 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 stat
dependencies on some files (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...@li
pect and use.
> >
> The usual 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.
Bernha
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
A
ise equal list of or'ed list).
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 conta
maller.
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 "un
ting in far too many
needlessly repackaged .orig.tar.gz 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...
n
> 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!
ick test: if I only use a program as user and
purge the package and my $HOME (and perhaps /tmp by reboot), there
should be nothing left and especially when I reinstall it everything
should be as after the first installation.
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, e
ctures, ..".
There is at least the case 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!"
gnore debian/patches as it is preapplied in .diff.gz"
or
"nothing special here, 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 t
did not give
because I would not understand them anyway 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
0 2001-05-12 05:51
./usr/lib/64/libfakeroot/libfakeroot.so -> libfakeroot.so.0.0.1
|>dpkg-deb -c libc6-sparc64_2.2.5-11.8_sparc.deb | 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
ith the next 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 &
X11/app-defaults/ to configure at least the interface, so this
should still be allowed.
I also think "window managers and display managers" is too strict. I
think it should rather be something that is not primary an single
application that happens to use X but everything that extends X
* Bernhard R. Link [090621 16:10]:
> > Configuration files for window managers and display managers
> > may be placed in a subdirectory of /etc/X11/
> > corresponding to the package name. Other X Window System
> > applicat
he grand total of
> three in 2003.
I agree 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 UNSUB
d say that each package should use
this tag to specifiy which entries in the Debian menu 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 UNSUBSCRIB
llow more minimal build chroots).
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
hes 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)
this. Does 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
a wishlist-bug 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
It becomes just a *pain* to use, if there is
only *one* programm or *one* icon with too much colours.
Hochachtungsvoll,
Bernhard R. Link
ted, the not-conffile should have
important comment saying it is not a conffile. (And a Sentence in policy
that this file has to)
Hochachtungsvoll,
Bernhard R. Link
49 matches
Mail list logo
