[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: maven2 for Debian



On Mon, Mar 05, 2007 at 02:11:41PM +0100, Arnaud Vandyck wrote:
> Hi Trygve,
> 
> On 3/5/07, Trygve Laugstøl <trygvis@apache.org> wrote:
> >Arnaud Vandyck wrote:
> >> On 3/4/07, Manfred Moser <manfred@mosabuam.com> wrote:
> >>> On Sunday March 4 2007 09:27, Michael Koch wrote:
> >>>
> >>> > I have built a preliminary Debian packages for Maven 2
> >>
> >> [...]
> 
> >To me the answer is obvious. As a user Maven should behave just like
> >upstream Maven, meaning that it will download from the internet and
> >install stuff under ~/.m2/repository. For a user having Maven download
> >to ~ is just the same as the user manually downloading the jars from the
> >project's CVS.
> 
> Maybe but I'd like an administrator to be able to override the default
> settings and to force Maven to ask the root password to install the
> package or to send a mail to root to let him/her install the
> package... from a Debian (only) repository.

You dont always want this. And its very hard to implement this.
We should provide basic maven functionality first before we try to climb
the highest mountains we can find.

> >For the dpkg builder Maven should still behave like Maven *but* with
> >some environmental changes it can comply with Debian's rules. If there
> >us a repository like you're suggesting under
> >/usr/share/java/maven2/repository and Build-Depend on the other packages
> >they will be included and Maven won't ever go out on the internet to
> >fetch packages.
> >
> >The only problem are the existing packages but they can either be
> >updated with symlinks under the repo or a tool to create a dummy repo
> >under a temporary location can be used.
> 
> Can we have a repository with files to describe where to find the
> jars? So that way, we don't even have to modify the location of all
> our jars.

I think writing some policy and implementing them in all java packages
is enough. The problem is to find the solution we want to implement.
I have to experiment more with Maven to get an opinion about this.

> >The only change that has to be done to the upstream sources is to add
> >the repository reference. That way there is no need to change the Maven
> >sources (yay), but you'll have to change the upstream pom.xml. Another
> >option is to add the repository to the root pom but then it will be used
> >for all builds which might not be optimal.
> 
> But 1° that's the only way to be sure the installed packages have been
> built by DD and so, you know who is responsible for the bugs and for
> the software to be DFSG; 2° that could be overriden by another
> pom.xml, isn't it?

As Trygve already wrote there are two main usecases for Maven in Debian.
We have to take care that both usecases are supported and work as they
should:

1) Debian package building: Never download anything. Depend only on
installed stuff (aka build dependencies).

2) Download stuff for the user when he wants to use some software
(version) not packaged in Debian.

> >The only requirement I have from the Debian packagers is that Maven from
> >Debian still behaves *exactly* like Maven from Apache from a users point
> >of view. If not I will not and can not support it in any way. This is
> >imperative to the success of packaging Maven 2 in Debian.
> 
> I understand your point of view and respect it. But as we are
> responsible in some way of the software we package and distribute, we
> cannot distribute a software for Debian that could install non free
> software in all ~'s.

Binary blobs are not non-free per so. If we would go your route we would
have to disable download functionality in e.g. iceweasel as you are
*able* to download non-free stuff with it. The download feature in Maven
is no problem per se. We just need to figure out how we exactly handle
non-installed dependencies.

> We have to discuss about that.

We have to.

> Maybe creating a "debian-restricted" mode or something like that and
> the user would have to add something in his/her envvars or in the pom
> file to override the restriction.

I dont see a reason to do this currently. There is no need to.


Cheers,
Michael
-- 
 .''`.  | Michael Koch <konqueror@gmx.de>
: :' :  | Free Java Developer <http://www.classpath.org>
`. `'   |
  `-    | 1024D/BAC5 4B28 D436 95E6 F2E0 BD11 5923 A008 2763 483B



Reply to: