On Wed, Mar 07, 2018 at 05:03:54PM +0200, Panu Matilainen wrote: > On 03/07/2018 03:48 PM, Vladimir D. Seleznev wrote: > > On Thu, Mar 01, 2018 at 09:58:58AM +0200, Panu Matilainen wrote: > >> On 02/28/2018 12:03 AM, Vladimir D. Seleznev wrote: > >>> Hello, rpm-maint@! > >>> > >>> We in ALT Linux Team implemented some new RPM tags for our RPM package > >>> header and RPM database. Since RPM tags are numerical identifiers and we > >>> want to keep compatibility with mainstream RPM tools and packages, we > >>> are requesting to reserve some RPM tag range for our purpose (around 100 > >>> RPM tags) to avoid the collision with RPM tag numbers, that can possibly > >>> will be added to rpm.org in the future. > >> > >> Yes we can reserve tags, it's not like we're going to run out of 32bit > >> integers anytime soon. However we're not going to foster distro > >> proprietary development & forks by blindly handing you 100 "do whatever > >> you want" tags. That's not how this works. > > > > This is not about proprietary development, all ALT rpm features are > > available in git repo at git.alt [1] [2]. > > Yes, I know. Of course it's not proprietary in the strict sense, but for > all practical purposes the results of that work are not available to > anybody not using ALT. I should've said "proprietary" with quotes. > > > It would be better to consolidate efforts but currently ALT rpm is a > > fork with more than a decade-long history and a lot of good features > > implemented such as autogenerated dependency for various interpreted > > languages, set-versions, checks and a lot of other enhancements, and we > > just can't drop these. Still we tried to port ours changes to new at > > that time rpm 4.13 to keep our rpm closer to upstream (for now it > > provides rpm(8) and some other, but no rpm-build). > > Yeah I know and I was glad to see that happen. > > > > >> If a feature is interesting to Alt, there's more than a slight change > >> it's interesting to others as well, so you should always initially > >> target getting the thing upstream. The price of tag reservations is > >> discussing your plans upstream first, either here on rpm-maint or GH > >> ticket/PR. > > > > And what about features ALT already has? They are integrated to ALT > > package ecosystem with repositories with thousands of packages which > > should be able to be installed and handled by package manager. And what > > about the features like set-versions, which you don't want to integrate > > [3]? > > Just send a patch that makes the reservations for the tags you already > use, with their actual names and types and all? See the RPMTAG_MSSF* > tags for an example of how to do it. If there are clashes or other > issues, the only way to work them out is by laying it all on the table. > > > > > We asked for 100 rpm tags with a big reserve. > Understood, but handing out a big pile of free tags to grab and run is > not going to bring your rpm any closer to upstream. Quite the contrary. > I'm just trying to encourage you folks into an upstream first approach > by whatever means I have available. If it feels a bit like extortion to > you, sorry ;) > > > At the moment we want to use RPMTAG_AUTOINSTALLED in rpm db that helps > > apt to determine what package was installed automatically as a > > dependency of manually installed packages. > > Tracking the install reason is a common need across pretty much all the > depsolvers. Send a patch and we'll see where it goes from there?
Ok, but the tag is just for record to RPM database, all the logic is on apt side. > > Second tag we want to use is RPMTAG_IDENTITY which determine a > > characteristic of package build and is represented hash of significant > > tags (in opposite to RPMTAG_SHA1HEADER, that is a hash of all package > > tags). > > A bit hard to comment based on just that, but if I understood correctly > then I don't see why not, sounds potentially quite useful in fact. Send > a patch so we can discuss the specifics? I should've explained the purpose of this tag more specific, but I think it is ALT specific one. It is a hash representation of build result that solves two main problems: * check reproducible build (the tag values of two builds are equal in that case); * generate more strict inter-subpackage dependencies. For now it isn't in ALT rpm code tree because we have to make some decisions. But is would be good to already have reserver rpm tag for it. > In recent years this here market has become quite a bit more open than > it once was and with many more parties involved. But nothing will get > upstreamed if it's not submitted at all. Even if upstream doesn't take > it right away, at least people will then be aware of the work and might > grow interested, which might lead to being used in other distros too -> > more pressure for upstream to include it. In some cases you might even > see others jump in to help with a feature, shock horror! And even if > nothing else comes out of it, at the very least you'll get your tags > reserved in time. Ok, then I'll prepare the patches to send here, but more likely I will send these patches in the next week. -- With best regards, Vladimir D. Seleznev _______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
