Package: wnpp
Severity: wishlist
Owner: Gabriele Giacone
* Package name: libfreehep-export-java
Version : 2.1.1
Upstream Author : FreeHEP team
* URL : http://java.freehep.org/
* License : LGPL-2.1+
Programming Lang: java
Description : FreeHEP Export and
Package: wnpp
Severity: wishlist
Owner: Gabriele Giacone
* Package name: libjas-plotter-java
Version : 2.2.6
Upstream Author : FreeHEP team
* URL : http://java.freehep.org/
* License : LGPL-2.1+
Programming Lang: java
Description : JAS(2) Plotter
FreeHE
Le Fri, Nov 27, 2009 at 02:28:26PM +0100, Raphael Hertzog a écrit :
> Obviously, we don't want to have many formats in the archive and it's best
> if "3.0 (quilt)" is flexible enough so that we don't have to invent many
> other formats.
Le Fri, Nov 27, 2009 at 02:49:39PM +0100, Raphael Hertzog a
Package: wnpp
Severity: wishlist
Owner: Gabriele Giacone
* Package name: libmaven-exec-plugin-java
Version : 1.1.1
Upstream Author : Jerome Lacoste , Kaare Nilsen
* URL : http://mojo.codehaus.org/exec-maven-plugin
* License : Apache-2.0
Programming Lang: ja
Package: wnpp
Severity: wishlist
Owner: nils
* Package name: seahaventowers
Version : 1.50
Upstream Author : Bill Spitzak spit...@d2.com
* URL : http://seahaven.sourceforge.net/
* License : other
Programming Lang: C++
Description : seahaven towers soli
Eugene Gorodinsky writes:
> No, on the contrary, I'm suggesting to have an additional format for
> software that is not system-specific and leaving the system-specific
> formats to do what they were designed for (i.e. manage system packages)
> rather than reducing the number of formats.
I don't
Sorry for the delay, I've been very busy last week.
>> A while ago I participated in a discussion here about the debian
>> package format. Quite recently I tried to spark up a discussion about
>> package formats on the LSB list but did not get any replies
>
>Can you point to the message (preferabl
> I've read that several times, but I still must be missing something.
>My impression is that your poins is essentially the following: 1. it's
>too much work for "small distros" to use any new format instead of one
>of the big established ones; 2. let's reduce the number of big
>established format
>Not to mention that the package format is not the only thing that matters.
>It is the contents of the package, the rules, specs and standards that are
>followed that cause the most differences.
I aggree, and I'm hoping to resolve this issue
>Oh and I guess I'm missing something, otherwise why wo
I believe RPM is not suited well enough for this job, it tries to do
everything rather than doing one thing and doing it well. The package
format I'm proposing has a few features rpm does not.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trou
Package: wnpp
Severity: wishlist
Owner: Philippe Seewer
* Package name: dracut
Version : 3.0
Upstream Author : Harald Hoyer
* URL : https://sourceforge.net/projects/dracut/
* License : GPLv2
Programming Lang: Shell
Description : A new initramfs infras
Package: wnpp
Severity: wishlist
Owner: David Watson
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: python-lockfile
Version : 0.8
Upstream Author : Skip Montanaro
* URL : http://smontanaro.dyndns.org/python/
* License : MIT
Programming Lang: Pyt
Package: wnpp
Severity: wishlist
Owner: Gabriele Giacone
* Package name: java3ds-fileloader
Version : 1.2
Upstream Author : Microcrowd
* URL : http://www.microcrowd.com/
* License : LGPL
Programming Lang: java
Description : Java3D 3DS FileLoader
Java
On Fri, 27 Nov 2009, Thibaut Paumard wrote:
> But the package is unpacked before it can be patched. The patches
> themselves are in debian/patches: when they become available,
> debian/source/options and debian/source/format are available as
> well.
Right, but unpacking should be under control of
Le 27 nov. 09 à 14:28, Raphael Hertzog a écrit :
On Fri, 27 Nov 2009, Charles Plessy wrote:
That would be a useful compromise. How about the second half, which
is to not
patch anything during the unpacking of the package? Maybe this
could be
combined in a single ‘no-patch’ option, or an ali
On Fri, 27 Nov 2009, Charles Plessy wrote:
> That would be a useful compromise. How about the second half, which is to not
> patch anything during the unpacking of the package? Maybe this could be
> combined in a single ‘no-patch’ option, or an alias like ’3.0 (simple)’?
There's already --skip-pat
16 matches
Mail list logo
