Re: [[PATCH setup] 0/3] Prepare for colons in version numbers
On 2017-10-31 12:15, Achim Gratz wrote: > Am 31.10.2017 um 12:21 schrieb Corinna Vinschen: >> Not sure what distros you're referring to. Of the 58467 packages >> in Fedora 26, 7822 are using epochs. > > I'm expecting as much since it was rpm that introduced the epoch IIRC (I think > an earlier approach was using a "serial number"). Debian is still using > epochs > in some places even though they've long provided facilities in apt to make > them > obsolete. The distro I can positively say doesn't use any epoch numbers is > openSUSE: > > https://en.opensuse.org/openSUSE:Package_naming_guidelines OpenSUSE mandates package version rules and provides special characters to mitigate any problems with upstream package version numbering, making the OpenSUSE package version independent of the upstream version unless it conforms: https://en.opensuse.org/openSUSE:Package_naming_guidelines#Handling_special_version_strings > The idea of the epoch is to provide a total ordering among all possible > version > numbers, which still doesn't work if the ordering gets changed > retroactivekly. > But a total ordering is not necessary to do in practise since you never keep > all > versions available in the install repo, so an ordering among the available > versions is all that matters. Another approach would be to add a packaging server release timestamp e.g. strftime %s metadata which provides ordering independent of versions. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Re: [ITA] ghostscript, ghostscript-fonts-std, ghostscript-fonts-other
On 10/31/2017 12:56 PM, Ken Brown wrote: On 10/30/2017 5:55 PM, Yaakov Selkowitz wrote: It would also be nice if the updated URW fonts[2] would also be installed under e.g. /usr/share/fonts/urw-base35. Is the attached what you had in mind? Following Fedora, I only packaged *.t1 and *.afm files, even though the source package also contains *.otf and *.ttf. Or did I misunderstand the second "also" in your mail above? Wouldn't it suffice to just install the fonts in /usr/share/fonts/urw-base35 and add this to the ghostscript search path? Ken
Re: [[PATCH setup] 0/3] Prepare for colons in version numbers
Am 31.10.2017 um 12:21 schrieb Corinna Vinschen: Not sure what distros you're referring to. Of the 58467 packages in Fedora 26, 7822 are using epochs. I'm expecting as much since it was rpm that introduced the epoch IIRC (I think an earlier approach was using a "serial number"). Debian is still using epochs in some places even though they've long provided facilities in apt to make them obsolete. The distro I can positively say doesn't use any epoch numbers is openSUSE: https://en.opensuse.org/openSUSE:Package_naming_guidelines The idea of the epoch is to provide a total ordering among all possible version numbers, which still doesn't work if the ordering gets changed retroactivekly. But a total ordering is not necessary to do in practise since you never keep all versions available in the install repo, so an ordering among the available versions is all that matters. -- Achim. (on the road :-)
Re: [ITA] ghostscript, ghostscript-fonts-std, ghostscript-fonts-other
On 10/30/2017 5:55 PM, Yaakov Selkowitz wrote:
It would
also be nice if the updated URW fonts[2] would also be installed under
e.g. /usr/share/fonts/urw-base35.
Is the attached what you had in mind? Following Fedora, I only packaged
*.t1 and *.afm files, even though the source package also contains *.otf
and *.ttf.
Ken
#
http://pkgs.fedoraproject.org/cgit/rpms/urw-base35-fonts.git/tree/urw-base35-fonts.spec
inherit font
NAME="urw-base35-fonts"
VERSION=20170801
RELEASE=1
CATEGORY="Graphics X11"
SUMMARY="The 35 fonts in the PostScript Level 2 Core Font Set"
DESCRIPTION="The 35 fonts in the PostScript Level 2 Core Font Set"
HOMEPAGE="https://github.com/ArtifexSoftware/urw-base35-fonts/;
SRC_URI="${HOMEPAGE}/archive/${VERSION}.tar.gz"
OBSOLETES="ghostscript-fonts-std"
src_compile() {
:
}
src_test() {
:
}
src_install() {
cd ${S}
fontinto ${NAME%-fonts}
dofont fonts/*.t1
dofont fonts/*.afm
insinto /usr/share/ghostscript/fonts
doins fonts/*.t1
doins fonts/*.afm
cd fontconfig
for f in *.conf
do
newfontconf ${f} 60-${f}
done
}
ARCH="noarch"
Re: [[PATCH setup] 0/3] Prepare for colons in version numbers
On 2017-10-31 05:21, Corinna Vinschen wrote: > On Oct 31 11:06, Achim Gratz wrote: >> Am 30.10.2017 um 16:58 schrieb Jon Turney: >>> "everyone" != "everyone, ignoring people who disagree with me" >> >> I think this is an unfair summary of my position. >> >>> If you think epochs are a bad idea, you need to give reasons, not just >>> pretend there is no debate. >> >> I was strictly talking about those folks who've had the opportunity in >> practise so far, which is all the major GNU/Linux distributions. The ones >> I'm aware of aren't using epochs and instead decided to use other means of >> achieving the same (or similar) goals. In fact they created rules to not >> use epochs even though the tools support them. Their line of reasoning >> always was (and still is), that once you start using epochs there is no way >> going back and you could just as well have used monotonic release numbers >> instead of versions. The other point is that it is close to impossible that >> everybody will agree on what the epoch ought to be. The last point is that >> once an epoch bump is introduced, you can't decide to sort things >> differently unless you're prepared to invalidate all existing released >> packages. > > Not sure what distros you're referring to. Of the 58467 packages > in Fedora 26, 7822 are using epochs. At ~13% that's a bit higher than Ubuntu/Debian Trusty with 5056/48423 ~10%. It does not appear that either of those bases use the epoch in the package archive names, only in the package manager. That may be the way to go - don't use the epoch field in the package archive name. If the epochs differ - the package versions are totally different in some way. If they are the same epoch, the packages are correctly ordered by a version sort, as supported in sort, ls, etc. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Re: [ITA] ghostscript, ghostscript-fonts-std, ghostscript-fonts-other
> On 30/10/2017 19:43, Ken Brown wrote: > > My cygport files and patch are attached. The two fonts packages > > don't need updating, but their cygport files had to be updated, so I'm > > attaching them for future reference. > > > > In the case of ghostscript, the current version is 9.22, but it > > doesn't work with preview-latex: > > > > https://bugs.ghostscript.com/show_bug.cgi?id=698680 > > > > So I propose to start with 9.21 until that issue is resolved. > > > > GTG > > all 3 package are yours. Gold stars awarded! https://cygwin.com/goldstars/#KB
Re: [[PATCH setup] 0/3] Prepare for colons in version numbers
On Oct 31 11:06, Achim Gratz wrote: > Am 30.10.2017 um 16:58 schrieb Jon Turney: > > "everyone" != "everyone, ignoring people who disagree with me" > > I think this is an unfair summary of my position. > > > If you think epochs are a bad idea, you need to give reasons, not just > > pretend there is no debate. > > I was strictly talking about those folks who've had the opportunity in > practise so far, which is all the major GNU/Linux distributions. The ones > I'm aware of aren't using epochs and instead decided to use other means of > achieving the same (or similar) goals. In fact they created rules to not > use epochs even though the tools support them. Their line of reasoning > always was (and still is), that once you start using epochs there is no way > going back and you could just as well have used monotonic release numbers > instead of versions. The other point is that it is close to impossible that > everybody will agree on what the epoch ought to be. The last point is that > once an epoch bump is introduced, you can't decide to sort things > differently unless you're prepared to invalidate all existing released > packages. Not sure what distros you're referring to. Of the 58467 packages in Fedora 26, 7822 are using epochs. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: [[PATCH setup] 0/3] Prepare for colons in version numbers
Am 30.10.2017 um 16:58 schrieb Jon Turney: "everyone" != "everyone, ignoring people who disagree with me" I think this is an unfair summary of my position. If you think epochs are a bad idea, you need to give reasons, not just pretend there is no debate. I was strictly talking about those folks who've had the opportunity in practise so far, which is all the major GNU/Linux distributions. The ones I'm aware of aren't using epochs and instead decided to use other means of achieving the same (or similar) goals. In fact they created rules to not use epochs even though the tools support them. Their line of reasoning always was (and still is), that once you start using epochs there is no way going back and you could just as well have used monotonic release numbers instead of versions. The other point is that it is close to impossible that everybody will agree on what the epoch ought to be. The last point is that once an epoch bump is introduced, you can't decide to sort things differently unless you're prepared to invalidate all existing released packages. So, we might have that debate now for Cygwin because we might finally use a library that supports epochs, but others have been there before us and concluded that epochs aren't worth the trouble. I don't see our situation with Cygwin different enough to come to a different conclusion than the distro folks and they've had many more brains to pick on this issue. I agree it does not work well for CPAN-style floating point version numbers, but that's your problem to solve, or not, however you like... You can stop using this particular example if it helps you not taking a right at Albuquerque each time version numbers come up. This is just one of many examples where two sets of sane versioning rules don't produce the same ordering. There are plenty of other examples where versioning upstream for whatever reason doesn't conform to whatever set of rules to make them sortable and it's not all that unheard of that upstream decides to change their rules once in a while even if they otherwise keep their stride. So whatever the reason, you will have to impose a sort order whenever there is a package that doesn't follow the rules builtin to setup and hence sorts incorrectly. You say epochs are _the_ way to do that and I'm pointing out that the distro folks have come to the conclusion that it isn't and are using different mechanisms. -- Achim. (on the road :-)
