[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
  Web www.spinics.net

Re: Fedora vs JPackage naming

On 02/17/2012 02:29 AM, Aleksandar Kurtakov wrote:
> I've spend enough time on getting this working and it really is now. 
> If your package installs pom.xml file it will have Provide:
> mvn(gid:aid) If your package is an osgi bundle it will have Provide:
> osgi(bundle-symbolic-name) If it installs pom.xml and is osgi bundle
> it will have both Provides. When in doubt just use that or use yum to
> tell you the package name.

Does it set the version properly too? I know that certain characters are
not allowed in the RPM version string so it would have to normalize it
somehow. Currently, we don't have this on RHEL 6, so I haven't actually
seen it in action.

The Fedora Release tag policy prevents proper versioning of
BuildRequires since important parts of the version string end up in the
Release tag for no good reason. Since RPM compares both the V and the R,
moving things from V to R doesn't really make sense. RPM also compares
text strings in both, and while it may not exactly match how maven or
osgi compares, I think it's better than nothing and at least internally

> I don't understand this point. We can not use maven gid:aid or osgi
> symbolic-name as package names. The mess will become way bigger in
> this case - it will be: * for maven packages use gid-aid as package
> names * for osgi packages use symbolic names * for jars that are
> neither - stick to the project names * for packages that are both
> maven and osgi ? - should we give the packager a choice? I don't feel
> it's right to ask osgi developers to care about maven and vise-versa
> so letting the packager makes a choice seems like the right choice.

I guess I would say to just pick one. If we have a policy that each
package must have a POM (or OSGI support---your choice), then each
package is also guarnateed to have a unique name in those systems.

> But just imagine the mess this will be !!! I'm definetely not looking
> for this. People should learn to use the virtual provides for the
> time being (until there is suitable! module system in java world).

OK, you have some point to this in that we can start using these names
and pretend that the package name doesn't exist. But this only works if
the artifact names and locations are fixed too, right?

> I'm really tired of seeing this remarks. It is my choice to make this
> tool this way and people should respect that. Everyone is free to
> come with better(where better means more suitable for him) ones

I never said anything bad about your tool. If you look at what I said,
my choice was 100% driven by bandwidth concerns and my crappy internet
speed. It had nothing to do with software even. As I think you know, I
used to use Eclipse a lot in the past (especially when I was doing Java
development), and if I was able to do development on my local machine
I'd probably be using it now.

So again, I have nothing bad to say about your tool. But, I wonder if
parts of it are not tied to the GUI, then we could prehaps reuse a lot
of code to provide a headless solution? I am not saying that you (or I)
would be willing to code such a thing, but I am wondering if it makes sense.

> There is one huge difference here - perl and python are modulized
> upstream, with every module having it's own tarball an release (most
> of the times). Thus this comparison is irrelevant here until this 
> happens upstream in java land.

So, should we wait for Jigsaw? Will Jigsaw actually solve anything? If
yes, then we could at least start to plan for it.

> If we want to be more of a product than a bunch of random packages I
> think that this things should be set distro wide so there are no
> distro wide and enforced in a way that we don't see the current mess.

Good point. But if there were such specific standards, a tool can
generate to such standards, and rpmlint already exists to complain about
such things, although I don't know that it's actually deployed for Fedora.
java-devel mailing list

[Home]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Red Hat 9 Bible]     [Fedora Bible]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]

Powered by Linux

  Web www.spinics.net