/packaging-manuals/virtual-package-names-list.txt
also mentioned it.
Thanks!
- Otto
--
Otto Kekäläinen
https://keybase.io/ottok
Seravo Oy and MariaDB Foundation
2016-07-02 20:12 GMT+01:00 Bill Allombert :
> Could you provide the list of the new virtual packages together with their
> description ?
>
> The page you link provide the list but no description.
The list and descriptions:
virtual-mysql-client - A MySQL database compatible client packa
Package: debian-policy
Found: 4.7.0.1
Tags: patch
When presenting the Vcs-Browser and Vcs- fields, start by showing
one typical example. With the illustration visible it is much easier for
a new maintainer to read and grasp the technical definition on what all
syntax is allowed and what it means.
Package: debian-policy
Found: 4.7.0.1
I would like to suggest the Debian Policy to recommend a specific
Debian package version string scheme in cases where upstream has no
releases, but they do have git commit ids to refer to:
***
In case your upstream does not use version numbers, the Debian pac
> Please recommend only putting this information into the changelog entry.
> It has no place in the version value.
Sorry, I don't understand, can you elaborate?
In the case of say for example canid 0.0~git20180613.007c9af-2, which
part of this version string do you think does not belong there and
> The commit hash. 007c9af.
OK, thanks.
I disagree here - to me the git commit hash is the single most
important identifier for the software version if there are no actual
releases.
Package: debian-policy
Found: 4.7.0.1
Currently
https://www.debian.org/doc/debian-policy/ch-source.html#source-package-handling-debian-readme-source
talks about `README.source`.
I suggest we would allow this file to alternatively be in Markdown
format, and spell the filename as `README.source(.m
Hi!
> Are there tools that automatically locate README.source and would need to be
> adapted to
> find README.source.md instead ?
Not to my knowledge. This file is consumed by humans / Debian
maintainers to learn about the source package. Most likely it is
accessed by typing $EDITOR debian/READM
> > On Wed, Nov 27, 2024 at 01:11:14PM -0800, Otto Kekäläinen wrote:
> >> Package: debian-policy
> >> Found: 4.7.0.1
> >>
> >> I would like to suggest the Debian Policy to recommend a specific
> >> Debian package version string scheme in cases wh
Hi,
> This would not constitute any sort of rejection for which maintainers of
> packages would need to be concerned. It does not mean anyone's
> practices should change.
>
> It does not mean that there is no policy (lowercase 'p') for these
> version strings in Debian.
What I am trying to expre
> On Sun, Dec 01, 2024 at 09:44:17PM -0800, Otto Kekäläinen wrote:
> > My intent here was to suggest specifically that the version of form
> > 0.0~git20130606.b00ec39-1 would be elevated as the Policy recommended
> > form, as it makes sense and is already most popular.
>
&g
> FWIW: On my KDE system, ``README.source`` gets opened in Kate, while a
> file ending with ``.md`` gets opened in Okular, which renders Markdown.
Like wise with both Bat (rust) and Glow (go), the most popular
command-line "colorized" viewers: only files ending with .md will be
correctly rendered
Hi Russ,
I haven't done policy suggestions before, so asking what expectations to have:
- Is including a patch recommended/useful for the policy maintainers
or likely waste of time?
- Is each suggestion expected to get feedback in a month or is the
frequency of policy suggestion reviews rarer?
>
Hi!
While the policy should, of course, not mention any specific packages,
I think it would be prudent to try to justify the suggested changes
with practical examples of packages using the versions in the ways you
describe.
Your text indicates that you want to continue using source format 1.0
for
Hi!
Due to how Gulliem expresses himself I find it hard to follow what the
core argument or request here is, but looking at the examples one can
slowly piece together what is special about them:
> When the consistency and coherence check was introduced for 3.0 formats,
> this affected:
>
> - 0
> > By rewriting the policy you can make it suddenly be "correct" to ignore
> > basic assumptions the entire Debian archive is built upon.
>
> This is not correct: the entire Debian archive is not built on this
> assumption. People have been using native 1.0-format packages this way for
> as long a
Hi,
> > The topic seems related to Ian's drive to start using the 1.0 source
> > format again for new packages, like he did in xtruss, despite my
> > recommendation and ignoring the example of how the same can and should
> > be done with format 3.0
> > (https://salsa.debian.org/salsa-ci-team/pipel
+1 to clarifying the DELAYED queue section. Please also include an
example dcut command on how to remove a package from the DELAYED queue
if the maintainer does not want to have it.
Personally I would much rather see a contribution being submitted to
my packages as a Merge Request on Salsa, than a
18 matches
Mail list logo
