[Bug 780666] New: Version Mismatch for Saxon Packages
https://bugzilla.novell.com/show_bug.cgi?id=780666 https://bugzilla.novell.com/show_bug.cgi?id=780666#c0 Summary: Version Mismatch for Saxon Packages Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Java AssignedTo: mvyskocil@suse.com ReportedBy: thomas.schraitle@suse.com QAContact: qa-bugs@suse.de CC: fs@suse.com Found By: Documentation Blocker: --- Hi, openSUSE 12.1 contains two official saxon packages: * saxon (version 6.5.5) for XSLT 1.0 * saxon8 for XSLT 2.0 This package naming worked very good so far. However, openSUSE 12.2 messed this up. :) Now, 12.2 contains a package "saxon" which includes version 9 (XSLT 2). This is very unfortunate as the jump from version 6 to version 9 is NOT a usual version upgrade. Saxon 6 is still needed and in use (for example, the DocBook stylesheets use them), although there won't be any major versions as it is in maintenance mode. Unfortunately, the DocBook stylesheets does not work with Saxon 9. That means, previous scripts which relies explicitly on version 6 do not work anymore. For this reason, I would strongly recommend to keep the package names introduced in previous versions. That means: * saxon (contains 6.5.5) * saxon8 * saxon9 I'm not sure, if saxon8 is really needed anymore. This package can probably replaced by saxon9. It is expected that Michael Kay (the developer for Saxon) will create a 10th release in the future. The above naming schema will keep all of them peacefully together. Thanks! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=780666
https://bugzilla.novell.com/show_bug.cgi?id=780666#c1
Thomas Schraitle
https://bugzilla.novell.com/show_bug.cgi?id=780666
https://bugzilla.novell.com/show_bug.cgi?id=780666#c2
Michal Vyskocil
https://bugzilla.novell.com/show_bug.cgi?id=780666
https://bugzilla.novell.com/show_bug.cgi?id=780666#c3
Thomas Schraitle
Well, don't you want to keep the maintenance of saxon at all? I personally dislike such xslt, docbook thingie, so cannot even test my changes.
Well, you may dislike these things, but others use them in their daily work (me and my team included). ;) If you need someone to test, count me as a volunteer. :)
Anyway - the downgrade of saxon is not possible - the best I can do it add saxon6 with 6.5.5 into Factory (would be that enough?)
Well, this is/was an error as they are different things: version 6.x supports XSLT 1.0, and version 9.x is for XSLT 2.0. I'm sorry if that's troublesome for you, but that's just the way it is. :) Ok, but anyway. If you can't revert this change to the way it was in openSUSE 12.1, the question is now, how we deal it in the future? The following options come to my mind: 1. Use saxon6 as package name and /usr/bin/saxon6 as script name 2. Use saxon6 as package name and /usr/bin/saxon as script name (conflicts with saxon9, probably. ) 3. Use saxon6 as package name and use /usr/bin/saxon as link which is created by the "alternatives" method (similar to the java command/link). 4. Others...? I'm not sure which one is the best, but I have a slight preference for option 2. That means, the "saxon" name isn't "owned" by anyone, but created on demand (as with the "java" command). All other versions (previous and future) contains the explicit major number in its script name, like saxon6, saxon9, saxon10... Drawback is, that someone can be surprised if someone changes from version 6 to version 9. What do you think? Would that be feasible? Thanks! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=780666
https://bugzilla.novell.com/show_bug.cgi?id=780666#c4
Michal Vyskocil
Hi Michal,
(In reply to comment #2)
Well, don't you want to keep the maintenance of saxon at all? I personally dislike such xslt, docbook thingie, so cannot even test my changes.
Well, you may dislike these things, but others use them in their daily work (me and my team included). ;) If you need someone to test, count me as a volunteer. :)
In fact you (or your team) should be maintainer - or at least reviewer of all packages related to documentation.
Ok, but anyway. If you can't revert this change to the way it was in openSUSE 12.1, the question is now, how we deal it in the future? The following options come to my mind:
The easiest would be rename saxon to saxon9, add /usr/bin/saxon to saxon6 and let have
1. Use saxon6 as package name and /usr/bin/saxon6 as script name 2. Use saxon6 as package name and /usr/bin/saxon as script name (conflicts with saxon9, probably. ) 3. Use saxon6 as package name and use /usr/bin/saxon as link which is created by the "alternatives" method (similar to the java command/link). 4. Others...?
I'm not sure which one is the best, but I have a slight preference for option 2. That means, the "saxon" name isn't "owned" by anyone, but created on demand (as with the "java" command). All other versions (previous and future) contains the explicit major number in its script name, like saxon6, saxon9, saxon10...
Drawback is, that someone can be surprised if someone changes from version 6 to version 9
Basically it's hard to tell which version is intended to be default one ... the u-a stuff complicates things, so my prefference is saxon$X -> /usr/bin/saxon$x we might do an exception the saxon6 will have /usr/bin/saxon to keep a compatibility with your tools ... Does it work for you? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=780666
https://bugzilla.novell.com/show_bug.cgi?id=780666#c5
Thomas Schraitle
In fact you (or your team) should be maintainer - or at least reviewer of all packages related to documentation.
Yes, you can assign the package to me.
[...]
Basically it's hard to tell which version is intended to be default one ... the u-a stuff complicates things, so my prefference is
saxon$X -> /usr/bin/saxon$x
we might do an exception the saxon6 will have /usr/bin/saxon to keep a compatibility with your tools ...
Does it work for you?
Yes, that's a good idea! Creating a link from /usr/bin/saxon6 to /usr/bin/saxon for compatibility reasons should work for us. It should be documented in the release notes as a deprecated link. After some time, we can remove it. Thanks! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=780666
https://bugzilla.novell.com/show_bug.cgi?id=780666#c6
Michal Vyskocil
https://bugzilla.novell.com/show_bug.cgi?id=780666
https://bugzilla.novell.com/show_bug.cgi?id=780666#c7
--- Comment #7 from Bernhard Wiedemann
https://bugzilla.novell.com/show_bug.cgi?id=780666
https://bugzilla.novell.com/show_bug.cgi?id=780666#c8
Frank Sundermeyer
https://bugzilla.novell.com/show_bug.cgi?id=780666
https://bugzilla.novell.com/show_bug.cgi?id=780666#c9
--- Comment #9 from Thomas Schraitle
[...] @toms: "saxon" is required by xep, jing, and epubcheck (and probably other packages). Do they require saxon6 or saxon9 or is the version irrelevant?
In case they require saxon6 we are in trouble...
The requirement was set long before the version mismatch of the Saxon packages. At that time they required the "saxon" package which was version 6.x. It hasn't changed, so all of the above packages you mentioned still require version 6.x. I doubt they work with version 9. That's one of the reasons we still need Saxon 6.x. Probably the best method is to introduce a conditional in the spec file of all affected packages. It can check for openSUSE 12.2 and sets the correct package name for Saxon. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=780666
https://bugzilla.novell.com/show_bug.cgi?id=780666#c10
Frank Sundermeyer
https://bugzilla.novell.com/show_bug.cgi?id=780666
https://bugzilla.novell.com/show_bug.cgi?id=780666#c11
Michal Vyskocil
https://bugzilla.novell.com/show_bug.cgi?id=780666
https://bugzilla.novell.com/show_bug.cgi?id=780666#c12
--- Comment #12 from Ludwig Nussel
https://bugzilla.novell.com/show_bug.cgi?id=780666
https://bugzilla.novell.com/show_bug.cgi?id=780666#c13
--- Comment #13 from Frank Sundermeyer
https://bugzilla.novell.com/show_bug.cgi?id=780666
https://bugzilla.novell.com/show_bug.cgi?id=780666#c14
--- Comment #14 from Ludwig Nussel
@lnussel: Just to keep you informed in your role as openSUSE release manager ...
That role is new to me :) For changes that could cause build failures or delays in the technical release schedule you may want to tell coolo. FWIW from my gut feeling the best practice would be IMO to have the 'saxon' package contain saxon 9 as saxon.sf.net lists saxon 9 as latest version. In addition a saxon6 package could be introduced that contains the old version for compatibility with tools that rely on the old version. You could even still introduce that package in 12.2. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=780666
https://bugzilla.novell.com/show_bug.cgi?id=780666#c15
Michal Vyskocil
@lnussel: Just to keep you informed in your role as openSUSE release manager ...
@mvyskocil: Yes, I think we can live with 12.2 not being fixed
Cool! Then I went through Java:packages and fortunatelly most of packages don't actually use it (it is mostly enabled in maven build). Then submitted fixed things xmlbeans - 143587 jakarta-commons-compress - 143582 jing - 143584 saxon9 - 143588 saxon6 - 143589 BTW: I'd say OBS cannot use symbols, so you still need to adjust the project configuration in order to get saxon6 as saxon - use Substitute in a project configuration https://en.opensuse.org/openSUSE:Build_Service_prjconf#Substitute Does it sounds good to you? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=780666
https://bugzilla.novell.com/show_bug.cgi?id=780666#c16
--- Comment #16 from Juergen Weigert
From the sr#'s Michal did above, it looks like that most packages actually work with saxon9 now, so Ludwig's approach appears fine. The remaining pakages(*) are few and can be changed to explicitly require saxon6.
(*) Which packages fail with saxon9? xep. epubcheck? Any other? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=780666
https://bugzilla.novell.com/show_bug.cgi?id=780666#c17
--- Comment #17 from Thomas Schraitle
[...]
XSLT-2.0 and is not backwards compatible.
Actually, this is not (entirely) true. :) I guess I need to shed some more light on this issue: According to the XSLT 2.0 spec (http://www.w3.org/TR/xslt20/#status): "Many new features have been added to the language (see J.2 New Functionality) while retaining a high level of backwards compatibility (see J.1 Incompatible Changes)." This "backwards compatibility" is definied in section 3.8 Backwards-Compatible Processing (http://www.w3.org/TR/xslt20/#backwards). So what does it mean? You *can* pass a XSLT 1.0 stylesheet to a XSLT 2.0 processor. In such a case, the 2.0 processor falls back to a 1.0 compatibility mode. However, this will only work if you stay completely in the *realm* of XSLT 1.0. As XSLT 1.0 was (and is) very restricted, there was an urgent need to add more functionality. For example, XSLT 1.0 can only create *one* output document which is one limitation and very unsatisfying. For such cases, XSLT provides in its core language the possibility to enhance its functionality with "extension functions and elements". Hence the X (eXtensible) in its name. However, such extensions are completely ouside of XSLT 1.0. They don't belong to the core language anymore and most of them are processor dependent. Unfortunately, to provide a certain functionality, the DocBook stylesheets, for example, has to rely on these extensions. Otherwise it wouldn't be possible to process a DocBook document and create several HTML files. Exactly these extensions create most of the problems. So it doesn't help to pass a XSLT 1.0 stylesheet which contains these extensions to a XSLT 2.0 processor -- it won't work as the 2.0 processor does not know these extensions. In other words, a 1.0 stylesheet which uses such extensions have to become a 2.0 stylesheet. It needs to be rewritten completely. This is not always as easy as it sounds. For the DocBook stylesheets, this is currently in progress. However, they are not finished yet and as such not in a production stable state as the 1.0 stylesheets. I guess, there are other stylesheets (TEI?) which need also extensions and are as such also "incompatible" with XSLT 2.0. Hope that gives you some more insight.
(*) Which packages fail with saxon9? xep. epubcheck? Any other?
Well, the most important part are the DocBook stylesheets. ;) They are based on XSLT 1.0 so they require a XSLT processor which understands version 1.0. This is the case for Saxon 6, but not for Saxon 9 (as I tried to explained above). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=780666
https://bugzilla.novell.com/show_bug.cgi?id=780666#c18
Michal Vyskocil
Please comment if this is correct, if so my vote is 'saxon9 provides saxon':
Only one of the two saxon6 or saxon9 should provide saxon. If saxon6 provides saxon, it should also have /usr/bin/saxon.
Yes, saxon6 provides saxon and /usr/bin/saxon in order to maintain backward compatibility. It's not the best approach, but it works. For the future development - what about having the /usr/bin/saxon-xslt2 and have xstl = 2.0 || saxon-xslt2 || /usr/bin/saxon-xslt2 || whatever in provides fo saxon${the-greatest}? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=780666
https://bugzilla.novell.com/show_bug.cgi?id=780666#c19
Michal Vyskocil
participants (1)
-
bugzilla_noreply@novell.com