Re: New source package formats now available

[Raphael Hertzog]

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-patches, but options in debian/source/options only
apply at build time obviously (and not at unpack time since that file is
not unpacked yet).

> Le Thu, Nov 26, 2009 at 12:30:12PM -0800, Russ Allbery a écrit :
> > I can understand not wanting, in the very long run, to support multiple 
> > patch
> > formats.
> 
> Does that mean that the use of options discussed above may become forbidden in
> our archive in the future? If yes, there is little point making concessions 
> now…

I don't understand how you can jump to that conclusion from this
discussion.

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. 

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Thibaut Paumard]

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 alias like ’3.0  
(simple)’?


There's already --skip-patches, but options in debian/source/options  
only
apply at build time obviously (and not at unpack time since that  
file is

not unpacked yet).


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.


Regards, Thibaut.

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Raphael Hertzog]

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 the unpacker and
not under control of the one who crafted the source package.

So it's still not a good idea. Furthermore I don't see at all
what putting this option in the source package would be used for.
If you don't want the patch system, you don't create patches with it but
creating patches only to not have them applied at unpack time is non-sense
IMO.

Cheers,
-- 
Raphaël Hertzog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#558259: ITP: java3ds-fileloader -- Java3D 3DS FileLoader

[Gabriele Giacone]

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

 Java3D 3DS FileLoader for platforms supporting JDK1.4 and Java 3D Highly
 functional, multiplatform 3DS File format loader. Supports: Heirarchical
 animation Cameras Point Lights Directional Lights Textures Smooth Groups
 and other features



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#558273: ITP: python-lockfile -- Platform-independent file locking module

[David Watson]

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: Python
  Description : Platform-independent file locking module

 The lockfile module exports a FileLock class which provides a simple API for
 locking files. Unlike the Windows msvcrt.locking function, the Unix
 fcntl.flock, fcntl.lockf and the deprecated posixfile module, the API is
 identical across both Unix (including Linux and Mac) and Windows platforms.
 The lock mechanism relies on the atomic nature of the link (on Unix) and
 mkdir (on Windows) system calls.

-- 
David Watson









-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#558274: ITP: dracut -- A new initramfs infrastructure

[Philippe Seewer]

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 infrastructure

 Unlike existing initramfs's, this is an attempt at having as little as
 possible hard-coded into the initramfs as possible.  The initramfs has
 (basically) one purpose in life -- getting the rootfs mounted so that
 we can transition to the real rootfs.  This is all driven off of
 device availability.  Therefore, instead of scripts hard-coded to do
 various things, we depend on udev to create device nodes for us and
 then when we have the rootfs's device node, we mount and carry on. 
 Having the root on MD, LVM2, LUKS is supported as well as NFS, iSCSI,
 NBD and FCOE.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Re: Package formats and software distribution on Linux

[Eugene Gorodinsky]

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". Trouble? Contact listmas...@lists.debian.org

Re: Re: Package formats and software distribution on Linux

[Eugene Gorodinsky]

>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 wouldn't shipping rpm
>and dpkg be enough to install either kind of packages?

Because not all distributions are redhat or debian based. There are many others.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Re: Package formats and software distribution on Linux

[Eugene Gorodinsky]

>  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 formats to one.

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.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Re: Package formats and software distribution on Linux

[Eugene Gorodinsky]

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 (preferably via its Message-Id field) so we
>can see what it was saying?
http://lists.debian.org/debian-devel/2009/07/msg00978.html
or
b28b6cf70907310348x5d233eebgf7433398fd7f3...@mail.gmail.com

>> hopefully this discussion will be more welcome here. Constructive
>> crticism is welcome, so feel free to critique.
>
>To be honest, I'm not sure what response you expect to get. There's not
>much substantive to respond to in your message: yes, it would be nice to
>have a common package format, but I don't see what in particular you're
>proposing be done about that.
>
>Such a discussion would IMO best be done at the freedesktop.org
>distribution collaboration forum ,
>to gather input from the various distributions. Perhaps you could post a
>more specific proposal there, and post here (and likely points in other
>distribution-specific discussion forums) inviting interested parties to
>join that thread.

Thanks for the hint. I've posted the specification on the
distributions mailing list. The spec can be found here:
http://lists.freedesktop.org/archives/distributions/2009-November/000350.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Package formats and software distribution on Linux

[Russ Allbery]

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 believe the distinction that you're apparently drawing between
system and non-system packages really exists in any meaningful way.  The
dpkg format is well-suited for managing any software that one would like
to install on the system, and I suspect Red Hat users would say the same
thing about RPM.  Both of them are general package formats with a slightly
different mix of features and tradeoffs.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#558322: ITP: seahaventowers -- seahaven towers solitaire game

[nils]

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 solitaire game

This is Seahaven Towers, a solitaire card game written for X11R4 and C++. With 
this program you can waste great amounts of time. As opposed to the common 
"solitare" which is actually Knondike, this game also requires some brain power 
in order to use it. This program also includes an "autoplay" button so you can 
see if the game can be solved and how to do it.

This is a classic program written by Terry Weissman and Charles Haynes.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#558330: ITP: libmaven-exec-plugin-java -- A plugin to allow execution of system and Java programs

[Gabriele Giacone]

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: java
  Description : Exec Maven Plugin

  A plugin to allow execution of system and Java programs



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New source package formats now available

[Charles Plessy]

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 écrit :
> Unpacking should be under control of the unpacker and
> not under control of the one who crafted the source package.

I think that this is a monopolist point of view:

 - You have two different softwares (a packaging software and a patch
   management software) and you bundle them together so that people who would
   like the former must also use the latter.

 - You present the removal of a feature like a costly solution (like when
   people were asked to pay an extra if they do not want to use Windows on their
   new PC).

 - You plan to break backward compatibility to force users to upgrade, by
   making 3.0 the default before it is widely adopted. Remember this each time
   you get a .docx document that you can not open.

 - You try to hijack the directory where your competitors are doing their work
   (debian/patches), by applying quilt patches that were not made for the
   format 3.0 (and sometimes fail).

Your design decisions make the format ‘3.0 (quilt)’ not particularly useful for
the maintainers who already implemented a workflow based on a VCS and a patch
management system (or a VCS that does both). Worse, it seems that it creates
problems when one wants to keep the patch and unpatch targets in debian/rules.
I would be interested in the other improvements, namely the possibility to use
.tar.bz2 original upstream sources, and the possibiltiy to store the debian
directory in a tar archive, but I can also keep on working with format 1.0 as
before.

Last question: is the use of the Format field in debian/control deprecated, or
can I use it for the packages that I would like to stay in the format 1.0?

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#558344: ITP: libjas-plotter-java -- JAS(2) Plotter

[Gabriele Giacone]

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
FreeHEP is a collection of Java libraries used in High Energy Physics.
.
JAS-plotter is needed by freehep-export



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#558345: ITP: libfreehep-export-java -- FreeHEP Export and Save As Library

[Gabriele Giacone]

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 Save As Library

Library to register filetypes (which can be loaded as plugin modules).
This library is used by VectorGraphics to allow new output formats 
to be added by adding new jar files to the classpath.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org