Hi, I can't attend the meeting this week. Also it seems to me IRC meeting is not the best option for everyone. Not all of us can join in the evening (or even worse night).
I add my comments to some question marks on Toshio's draft page. Current draft is well written and should be usefull also for SCL beginners. My biggest concern here is the naming propose. I don't want to create such big incompatibility between downstreams. It would mean much more work for all interested parties, maybe changes in scl-utils. I'm not sure why it's needed in this format. Could someone elaborate?
https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_%28draft%29#Naming...
Thanks, Marcela
On Thu, Oct 31, 2013 at 04:14:48PM +0100, Marcela Mašláňová wrote:
Hi, I can't attend the meeting this week. Also it seems to me IRC meeting is not the best option for everyone. Not all of us can join in the evening (or even worse night).
The FPC needs to be able to discuss this "in person" because it's contentious and we need to convince enough FPC members that the alternatives won't work. Doing that over email could be done but we'd need to take one topic, discuss it to death, and record on a separate page what the pros and cons of each proposal to fix the topic was. Then move on to the next contentious topic.
mschwendt has also very accurately noted that getting a majority of FPC members to weigh in on topics via email has been hard (my guess is because etiquette is to not do +1/-1 in email or write short "What do you think about this one-line proposal?" emails and that's very necessary when working on these things so that we can establish what people are actually okay with).
OTOH, there are a number of non-controversial points to clarify in the guidelines. We could probably go through those on the mailing list. I think the last time I posted a long punch list of issues I made the mistake of mixing controversial nad non-controversial subjects so it wasn't easy to discuss just the easy, factual and stylistic changes needed.
I add my comments to some question marks on Toshio's draft page. Current draft is well written and should be usefull also for SCL beginners. My biggest concern here is the naming propose. I don't want to create such big incompatibility between downstreams. It would mean much more work for all interested parties, maybe changes in scl-utils. I'm not sure why it's needed in this format. Could someone elaborate?
https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_%28draft%29#Naming...
A prefix is necessary to make the scl packages unique from non-scl packages.
I did mention that the downstream naming was wrong and would need to be changed a long time ago. At the time I heard that people were resistant to scl- as a prefix but might be okay with $vendor-. I've been working to see if the latter would make sense.
-Toshio
On Thu, Oct 31, 2013 at 08:47:48AM -0700, Toshio Kuratomi wrote:
A prefix is necessary to make the scl packages unique from non-scl packages.
As a sysadmin, this seems obvious to me. Marcela, can you explain the reasoning in _not_ doing it?
On 31/10/13 17:22, Matthew Miller wrote:
On Thu, Oct 31, 2013 at 08:47:48AM -0700, Toshio Kuratomi wrote:
A prefix is necessary to make the scl packages unique from non-scl packages.
As a sysadmin, this seems obvious to me. Marcela, can you explain the reasoning in _not_ doing it?
Packages are already unique. They have prefix e.g. ruby193. If we force packagers add scl-ruby193 prefix, would it be more unique? To not have two same names for collection should be solved by Change proposal approved probably by FESCo.
Marcela
On Fri, Nov 01, 2013 at 11:34:58AM +0100, Marcela Mašláňová wrote:
As a sysadmin, this seems obvious to me. Marcela, can you explain the reasoning in _not_ doing it?
Packages are already unique. They have prefix e.g. ruby193. If we force packagers add scl-ruby193 prefix, would it be more unique?
Not just unique in the name-collision aspect, but unique in that:
1) it's going to be putting files in a different place than a normal rpm 2) it's going to need to be activated in a special way 3) it avoids conflict with possible versioned RPMs packaged in the traditional way 4) it was my understanding that SCL spec files could be built as either scls or regular packages. Without the special name, how will one easily tell which it is?
On 01/11/13 13:33, Matthew Miller wrote:
On Fri, Nov 01, 2013 at 11:34:58AM +0100, Marcela Mašláňová wrote:
As a sysadmin, this seems obvious to me. Marcela, can you explain the reasoning in _not_ doing it?
Packages are already unique. They have prefix e.g. ruby193. If we force packagers add scl-ruby193 prefix, would it be more unique?
Not just unique in the name-collision aspect, but unique in that:
- it's going to be putting files in a different place than a normal rpm
Why should user care about installation path?
- it's going to need to be activated in a special way
Yes, but users has to know about the activation anyway.
- it avoids conflict with possible versioned RPMs packaged in the traditional way
- it was my understanding that SCL spec files could be built as either scls or regular packages. Without the special name, how will one easily tell which it is?
Sure, without rubygem-1.2.3 with scl ruby193-rubygem-1.2.3. User has to know that he wants ruby193 collection anyway and he has to execute "scl enable ruby193", so scl prefix won't give him the knowledge.
I leave space for ideas to other people now, I still see scl prefix as ugly and uneccesary.
Marcela
On Fri, Nov 01, 2013 at 01:58:02PM +0100, Marcela Mašláňová wrote:
Not just unique in the name-collision aspect, but unique in that:
- it's going to be putting files in a different place than a normal rpm
Why should user care about installation path?
When the users are system administrators, it's part of their jobs to care.
Same with the package names, really. The end-users/developers might not care about either, but in that case, it also doesn't hurt to have a prefix.
Matthew Miller (mattdm@fedoraproject.org) said:
On Fri, Nov 01, 2013 at 01:58:02PM +0100, Marcela Mašláňová wrote:
Not just unique in the name-collision aspect, but unique in that:
- it's going to be putting files in a different place than a normal rpm
Why should user care about installation path?
When the users are system administrators, it's part of their jobs to care.
Same with the package names, really. The end-users/developers might not care about either, but in that case, it also doesn't hurt to have a prefix.
I would argue that SCL packages don't need a prefix in the package name in the same way that google-chrome doesn't (appear to) need a prefix to handle its installation in /opt.
Bill
On Fri, Nov 01, 2013 at 11:34:58AM +0100, Marcela Mašláňová wrote:
On 31/10/13 17:22, Matthew Miller wrote:
On Thu, Oct 31, 2013 at 08:47:48AM -0700, Toshio Kuratomi wrote:
A prefix is necessary to make the scl packages unique from non-scl packages.
As a sysadmin, this seems obvious to me. Marcela, can you explain the reasoning in _not_ doing it?
Packages are already unique. They have prefix e.g. ruby193. If we force packagers add scl-ruby193 prefix, would it be more unique? To not have two same names for collection should be solved by Change proposal approved probably by FESCo.
python2.6 -- mainstream compat package python2.6-requests -- requests module built for the mainstream compat package
python2.6 -- python2.6 SCL metapackage name that you seem to be proposing. Naming conflict is obvious here. scl-python2.6 -- python2.6 SCL metapackage with no naming conflict.
scl-python2.6-python-requests -- The horrible name that I believe you are refering to. This is controlled by the following portion of the proposed Guideline:
Name must be modified like this: -Name: foo +Name: %{?scl_prefix}foo
python2.6-python-requests -- The almost as horrible name that I believe you wish to use instead. This is the result of removing the prefix denoting that this is not a mainstream package from %scl_prefix. Note that with the current macros in place this would still leave the metapackage name conflicting. To rectify that I'm guessing that you want to change the definition of %scl_prefix something like this:
-%global scl_name>------->-------%{scl} +%global scl_name>------->-------%(echo %{scl}| sed s/^scl-//)
scl-python2.6-requests -- My preferred name for the scl packaged requests module as it actually removes the redundant information (we already know this is a python module) instead of the helpful information (now we know that this is a package that is part of an scl). This is can be expressed via a change to the proposed Guidelines. Instead of specifying that general scl package names must be %{scl_prefix}python-foo we can specify that scl package names can be %{scl_prefix}foo. I think we'll need to reference the addon package naming guidelines to explain how people should do this.
Something like: In general, Name is constructed by prepending scl_prefix to the existing package name like this [example]. However, to avoid redundancy, addon packages should remove the information that is already present in the scl_prefix like this: # If scl_prefix is scl-python2.6 then %if %{scl_prefix} Name: %{scl_prefix}foo %else Name: python-foo %endif
-Toshio
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 01/11/2013 17:33, Toshio Kuratomi a écrit :
Something like: In general, Name is constructed by prepending scl_prefix to the existing package name like this [example]. However, to avoid redundancy, addon packages should remove the information that is already present in the scl_prefix like this:
I agree, this will make package name really simpler
# If scl_prefix is scl-python2.6 then %if %{scl_prefix} Name: %{scl_prefix}foo %else Name: python-foo %endif
This should probably be done more generally to be usable everywhere the prefix is used (I mostly think of dependencies).
%global pkg_prefix %{?scl_prefix}%{!?scl_prefix:python-}
Name : %{pkg_prefix}foo BuildRequires: %{pkg_prefix}devel BuildRequires: %{pkg_prefix}bar
Still the "main" package problem (python26-python), which is not a big issue, as scl-python26 will requires scl-python26-python and scl-python26-devel will be what it is expected to be.
Remi.
Quoting Toshio Kuratomi (2013-11-01 17:33:56)
scl-python2.6-requests -- My preferred name for the scl packaged requests module as it actually removes the redundant information (we already know this is a python module) instead of the helpful information (now we know that this is a package that is part of an scl). This is can be expressed via a change to the proposed Guidelines. Instead of specifying that general scl package names must be %{scl_prefix}python-foo we can specify that scl package names can be %{scl_prefix}foo. I think we'll need to reference the addon package naming guidelines to explain how people should do this.
Something like: In general, Name is constructed by prepending scl_prefix to the existing package name like this [example]. However, to avoid redundancy, addon packages should remove the information that is already present in the scl_prefix like this: # If scl_prefix is scl-python2.6 then %if %{scl_prefix} Name: %{scl_prefix}foo %else Name: python-foo %endif
That is exactly why I think removing prefix is a bad idea. It complicates already complex spec files even further for not good reason except aesthetics. Not to mention complicating guidelines. We *know* people have a hard time following current guidelines. Do you honestly believe they will be able to follow something like "Do X unless Y is set, but if Z is set together with Y do Q"? We should try hard to keep guidelines simple to the core. Best practices are one thing, guidelines are something else.
Also newsflash: most users don't care how the RPMs are named. They care if the RPMs fulfill their needs.
On 11/01/2013 05:33 PM, Toshio Kuratomi wrote:
On Fri, Nov 01, 2013 at 11:34:58AM +0100, Marcela Mašláňová wrote:
On 31/10/13 17:22, Matthew Miller wrote:
On Thu, Oct 31, 2013 at 08:47:48AM -0700, Toshio Kuratomi wrote:
A prefix is necessary to make the scl packages unique from non-scl packages.
As a sysadmin, this seems obvious to me. Marcela, can you explain the reasoning in _not_ doing it?
Packages are already unique. They have prefix e.g. ruby193. If we force packagers add scl-ruby193 prefix, would it be more unique? To not have two same names for collection should be solved by Change proposal approved probably by FESCo.
python2.6 -- mainstream compat package python2.6-requests -- requests module built for the mainstream compat package
python2.6 -- python2.6 SCL metapackage name that you seem to be proposing. Naming conflict is obvious here. scl-python2.6 -- python2.6 SCL metapackage with no naming conflict.
scl-python2.6-python-requests -- The horrible name that I believe you are refering to. This is controlled by the following portion of the proposed Guideline:
Name must be modified like this: -Name: foo +Name: %{?scl_prefix}foopython2.6-python-requests -- The almost as horrible name that I believe you wish to use instead. This is the result of removing the prefix denoting that this is not a mainstream package from %scl_prefix. Note that with the current macros in place this would still leave the metapackage name conflicting. To rectify that I'm guessing that you want to change the definition of %scl_prefix something like this:
-%global scl_name>------->-------%{scl} +%global scl_name>------->-------%(echo %{scl}| sed s/^scl-//)scl-python2.6-requests -- My preferred name for the scl packaged requests module as it actually removes the redundant information (we already know this is a python module) instead of the helpful information (now we know that this is a package that is part of an scl). This is can be expressed via a change to the proposed Guidelines. Instead of specifying that general scl package names must be %{scl_prefix}python-foo we can specify that scl package names can be %{scl_prefix}foo. I think we'll need to reference the addon package naming guidelines to explain how people should do this.
Something like: In general, Name is constructed by prepending scl_prefix to the existing package name like this [example]. However, to avoid redundancy, addon packages should remove the information that is already present in the scl_prefix like this: # If scl_prefix is scl-python2.6 then %if %{scl_prefix} Name: %{scl_prefix}foo %else Name: python-foo %endif-Toshio
-- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
If I understand correctly you want to remove part of the name to make the name shorter. I disagree. The prefix marks packages as beeing part of a collection. Also what would happen if someone build it without prefix? It would bring more confusion than good.
Marcela
On Tue, Nov 05, 2013 at 01:18:12PM +0100, Marcela Mašláňová wrote:
If I understand correctly you want to remove part of the name to make the name shorter. I disagree. The prefix marks packages as beeing part of a collection.
Yep. And therefore the prefix doesn't change.in my proposal.
Also what would happen if someone build it without prefix?
How do you do that?
(OTOH: this proposal is simply to address your complaint that the names are ugly. I'm okay with going forward with the ugly names if that's the preference. I'm just saying that if you wantto un-uglify the names, don't look at shrinking the scl_prefix; look at shrinking the package name. The package name is where redundant information is being stored so it's the only place that we can actually affect how ugly the name is.
-Toshio
----- Original Message -----
A prefix is necessary to make the scl packages unique from non-scl packages.
I did mention that the downstream naming was wrong and would need to be changed a long time ago.
I could find places where you mentioned that it was wrong, but I didn't find any reasoning. Could you please state why you think the downstream naming is wrong?
Thanks, Slavek.
On Fri, Nov 01, 2013 at 03:37:21AM -0400, Bohuslav Kabrda wrote:
----- Original Message -----
A prefix is necessary to make the scl packages unique from non-scl packages.
I did mention that the downstream naming was wrong and would need to be changed a long time ago.
I could find places where you mentioned that it was wrong, but I didn't find any reasoning. Could you please state why you think the downstream naming is wrong?
Just replied to mmaslano -- I believe I've only mentioned it onlist because I discussed it with mmaslano on IRC and with langdon in #scl on freenode when doing the initial review of the draft. Apologies for that, I assumed from mmaslano's comments that there was an scl team that was actively discussing a prefix (using a vendor) and that she would carry back the rationale as to why no prefix wouldn't work.
-Toshio
On 11/01/2013 05:36 PM, Toshio Kuratomi wrote:
On Fri, Nov 01, 2013 at 03:37:21AM -0400, Bohuslav Kabrda wrote:
----- Original Message -----
A prefix is necessary to make the scl packages unique from non-scl packages.
I did mention that the downstream naming was wrong and would need to be changed a long time ago.
I could find places where you mentioned that it was wrong, but I didn't find any reasoning. Could you please state why you think the downstream naming is wrong?
Just replied to mmaslano -- I believe I've only mentioned it onlist because I discussed it with mmaslano on IRC and with langdon in #scl on freenode when doing the initial review of the draft. Apologies for that, I assumed from mmaslano's comments that there was an scl team that was actively discussing a prefix (using a vendor) and that she would carry back the rationale as to why no prefix wouldn't work.
-Toshio
-- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
Yeah, we were discussing some vendor prefix to make a distinction between collections with same content and same name. We were thinking about user or vendor not general scl. We are still discussing the best way, because currently redefinition of /opt/vendor is not nice. There is needed a fix in scl-utils: https://bugzilla.redhat.com/show_bug.cgi?id=985336
Marcela
On Tue, Nov 05, 2013 at 12:58:30PM +0100, Marcela Mašláňová wrote:
Yeah, we were discussing some vendor prefix to make a distinction between collections with same content and same name. We were thinking about user or vendor not general scl. We are still discussing the best way, because currently redefinition of /opt/vendor is not nice. There is needed a fix in scl-utils: https://bugzilla.redhat.com/show_bug.cgi?id=985336
the last reply to that bug seems to say that prefixing the package names with the vendor is the way to go.
-Toshio
On 11/05/2013 06:58 PM, Toshio Kuratomi wrote:
On Tue, Nov 05, 2013 at 12:58:30PM +0100, Marcela Mašláňová wrote:
Yeah, we were discussing some vendor prefix to make a distinction between collections with same content and same name. We were thinking about user or vendor not general scl. We are still discussing the best way, because currently redefinition of /opt/vendor is not nice. There is needed a fix in scl-utils: https://bugzilla.redhat.com/show_bug.cgi?id=985336
the last reply to that bug seems to say that prefixing the package names with the vendor is the way to go.
This way has one another benefit that I haven't seen mentioned yet. Since files that have to be located outside of SCL root (like systemd unit files, logrotate files, ...) cannot conflict with files from core system, we usually need to prefix them with SCL name. So we end for example with /etc/logrotate.d/mariadb55-mariadb.
However, imagine we wanted to install two collections with the same name (mariadb55) and different vendor (fedora vs. skysql) -- then the files outside SCL root would conflict and we wouldn't be able to install them. Including vendor into collection name will solve this, even though the service names get even more ugly: "systemctl status fedora-mariadb55-mariadb"
Honza
On 11/06/2013 10:40 PM, Bill Nottingham wrote:
Honza Horak (hhorak@redhat.com) said:
However, imagine we wanted to install two collections with the same name (mariadb55) and different vendor (fedora vs. skysql)
I'm not saying we can't make it a possibility, but I am curious why we would ever want to do that?
Hm, you're right, that's probably too much already. It doesn't make much sense to have two versions of the same SCL from two different vendors.
Honza
On 11/06/2013 10:40 PM, Bill Nottingham wrote:
Honza Horak (hhorak@redhat.com) said:
However, imagine we wanted to install two collections with the same name (mariadb55) and different vendor (fedora vs. skysql)
I'm not saying we can't make it a possibility, but I am curious why we would ever want to do that?
Bill
packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
I'm not saying we should do it in supported collections in Fedora, but it's possible people will do it. They can have different build options or add some ugly module, which we wouldn't ship.
Marcela
On 31/10/13 16:47, Toshio Kuratomi wrote:
On Thu, Oct 31, 2013 at 04:14:48PM +0100, Marcela Mašláňová wrote:
Hi, I can't attend the meeting this week. Also it seems to me IRC meeting is not the best option for everyone. Not all of us can join in the evening (or even worse night).
The FPC needs to be able to discuss this "in person" because it's contentious and we need to convince enough FPC members that the alternatives won't work. Doing that over email could be done but we'd need to take one topic, discuss it to death, and record on a separate page what the pros and cons of each proposal to fix the topic was. Then move on to the next contentious topic.
mschwendt has also very accurately noted that getting a majority of FPC members to weigh in on topics via email has been hard (my guess is because etiquette is to not do +1/-1 in email or write short "What do you think about this one-line proposal?" emails and that's very necessary when working on these things so that we can establish what people are actually okay with).
I concure.
OTOH, there are a number of non-controversial points to clarify in the guidelines. We could probably go through those on the mailing list. I think the last time I posted a long punch list of issues I made the mistake of mixing controversial nad non-controversial subjects so it wasn't easy to discuss just the easy, factual and stylistic changes needed.
I agree it's hard to follow conversation about so many paragraphs. It would be doable to discuss the problematic paragraphs. I'm afraid not many users or packagers will attend fpc meetings, so their views are not heard at all and they might have different and usefull views.
I add my comments to some question marks on Toshio's draft page. Current draft is well written and should be usefull also for SCL beginners. My biggest concern here is the naming propose. I don't want to create such big incompatibility between downstreams. It would mean much more work for all interested parties, maybe changes in scl-utils. I'm not sure why it's needed in this format. Could someone elaborate?
https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_%28draft%29#Naming...
A prefix is necessary to make the scl packages unique from non-scl packages.
I did mention that the downstream naming was wrong and would need to be changed a long time ago. At the time I heard that people were resistant to scl- as a prefix but might be okay with $vendor-. I've been working to see if the latter would make sense.
-Toshio
-- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
Marcela
packaging@lists.fedoraproject.org
-
Bill Nottingham -
Bohuslav Kabrda -
Honza Horak -
Marcela Mašláňová -
Matthew Miller -
Remi Collet -
Stanislav Ochotnicky -
Toshio Kuratomi