You don't need to add the release date any more, just rebuild it. Reproducible: Always
Created attachment 178264 [details] foomatic-db-3.0.ebuild
Created attachment 178267 [details] foomatic-db-engine-3.0.ebuild
Created attachment 178269 [details] foomatic-filters-3.0.ebuild
Created attachment 178270 [details] foomatic-filters-ppds-3.0.ebuild
Created attachment 178374 [details, diff] cups.diff
linuxprinting.org offers snapshots which change on a daily basis, that would break manifests every single day. That's why we take the snapshots every once in a while and add it to the tree with the date the snapshot was taken as version (latest one in tree is 20080507). Feel free to reopen if there's something which got added to foomatic and isn't provided by the latest snapshot in the tree. Also please attach diffs instead of full ebuilds for version bumps and give some details about your changes if they're not obvious. This saves us some time and thus will most likely speed up the process of bumping.
(In reply to comment #6) > linuxprinting.org offers snapshots which change on a daily basis, that would > break manifests every single day. That's why we take the snapshots every once > in a while and add it to the tree with the date the snapshot was taken as > version (latest one in tree is 20080507). It doesn't if you don't change the package file on your mirrors side. Anyway, the manifest changes every time when you publish a new release on your gentoo servers. Also, Foomatic snapshots aren't permanent on their ftp servers but the "current" tar file is. The only constraint is that people won't see any new releases until they force an emerge -1 foomatic-xx. They will do it anyway if you warn them during a cups upgrade like you do with other packages when they call plugins (xf86- packages family and xorg-server for instance). Please reconsider my request again.
(In reply to comment #7) > It doesn't if you don't change the package file on your mirrors side. But that's what would have to be done when we take your approach every time we would "bump" that package, it would cause a major mess across the mirrors as already seen multiple times when upstream changed the tarball and we have to redistribute it across the mirrors and update manifests. There are many people not syncing every day, so if you change the tarball in the meantime they'll get a bad manifest/digest error when trying to install the package. If you need an example see bug #241216. > The only constraint is that people won't see any > new releases until they force an emerge -1 foomatic-xx. They will do it anyway > if you warn them during a cups upgrade like you do with other packages when > they call plugins (xf86- packages family and xorg-server for instance). The xf86- packages are a bad example since you don't need to rebuild them to get a new feature or update them, but to get them (same version you've already installed) to work again after you've updated xorg-server. Package upgrades must be done by the package manager, not by telling people they should update something by a warning issued by another ebuild. We simply need versioned packages if we ever want to stabilize something or if any other package depends on a specific snapshot. Consider some feature got added which wasn't available on older tarballs, how should another ebuild depend on the new version then?
(In reply to comment #8) > There are many people not syncing every day, so if you change the tarball in > the meantime they'll get a bad manifest/digest error when trying to install the > package. > > If you need an example see bug #241216. > That's not the right way to use emerge has I understand. It would better to tell beginners to always syncing before emerging. Anyway, that's is a bad example too. You will get a lot of errors about the name or family of a package that has been renamed by its maintainers. That's is why you advertise a distpatch-conf in that case after an emerge --sync or you force the upgrade of portage when emerging. > Package upgrades must be done by the package manager, not by telling people > they should update something by a warning issued by another ebuild. > Communication is always better then nothing. As I can read there is a lot of packages that contains einfo() or ewarning(). > We simply need versioned packages if we ever want to stabilize something or if > any other package depends on a specific snapshot. Consider some feature got > added which wasn't available on older tarballs, how should another ebuild > depend on the new version then? > I agree. I didn't say you have to change your point of view. That all right. But people who use gentoo are special people, because they have special needs. Otherwise they would be happier with an other distribution more ... conventional or user friendly. In the portage tree I can read -9999 bzr, svn, git, darcs or whatever packages. Also why not propose versioned foomatic packages and a masked package like I asked for. It doesn't need any maintenance and there isn't any inconvenient for your users, especially if you don't put the tar file on your mirror servers. Moreover, It is zero effort to maintain.
> In the portage tree I can read -9999 bzr, svn, git, darcs or whatever packages. > Also why not propose versioned foomatic packages and a masked package like I > asked for. OK, let's rename this bug for what it actually is
